I do that to check if the size of the file to download has changed since the
user paused the download (could be a very long pause) and check if the server
has resume capabilities, if that helps:
protected function onDownloadResponseStatus(event:HTTPStatusEvent):void {
urlStream.removeEventListener(HTTPStatusEvent.HTTP_RESPONSE_STATUS,
onDownloadResponseStatus); var header:URLRequestHeader;
if (event.status == OK || event.status == PARTIAL_CONTENT)
for each (header in event.responseHeaders) { if (header.name ==
"Accept-Ranges" && header.value == "bytes") {
hasResumingCapabilities = true; } else if
(header.name == "Content-Length") { const
contentLength:Number = parseInt(header.value);
traceInfo("onDownloadResponseStatus", "contentLength: " + contentLength);
if (fileDescriptor.bytesTotal > 0 && fileDescriptor.bytesTotal -
fileDescriptor.bytesLoaded != contentLength) { abort();
run([ fileDescriptor ]); return;
} } }
dispatcher.dispatchArbitraryEvent(new
ResumableStatusEvent(hasResumingCapabilities)); }
Frédéric THOMAS
> Date: Fri, 25 Jul 2014 15:13:18 +0100
> From: t...@extravision.com
> To: dev@flex.apache.org
> Subject: Re: [DRAFT 2] 4.13.0 Announcement
>
> I haven't checked the servers in question, but unless they are returning
> etag or last-modified that we trust, we still need to fetch the whole
> file and then checksum it ?
>
> Not that I understand why having lots of data means it needs anything as
> complicated as a AIR application...
>
> Tom
>
> On 25/07/14 15:04, Kessler CTR Mark J wrote:
> > The http request method "HEAD" should work. Standard ones you are used to
> > are "GET" and "POST". The HEAD method simply checks the header which can
> > tell it things like date modified and size.
> >
> > " This method can be used for obtaining metainformation about the entity
> > implied by the request without transferring the entity-body itself. This
> > method is often used for testing hypertext links for validity,
> > accessibility, and recent modification. " [1] Section 9.4
> >
> >
> >
> > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
> >
> >
> > -Mark
> >
> > -----Original Message-----
> > From: Alex Harui [mailto:aha...@adobe.com]
> > Sent: Friday, July 25, 2014 9:52 AM
> > To: dev@flex.apache.org; Tom Chiverton
> > Subject: Re: [DRAFT 2] 4.13.0 Announcement
> >
> > Because it adds up to gigs of data.
> > Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
> >
> > Tom Chiverton <t...@extravision.com> wrote:
> >
> >
> > Why's this an AIR app ?
> > Surely a bit of bash that pulls the file once an hour, checks the size
> > and hash, and then runs the svn commands would be easier ?
> >
> > Tom
> >
> > On 25/07/14 08:06, Alex Harui wrote:
> >> Technically, we are good to go, but I've chickened out of pushing the
> >> announcement because I am trying to finish up an AIR app that will at
> >> least monitor the checksums, and maybe even auto-update the config.xml
> >> file. The worst case scenario is we announce, 500 folks start downloading
> >> and moments after the announce Adobe updates the playerglobal or AIR SDK
> >> and 500 folks fail to install while we are sleeping. But if folks think
> >> we should just announce then we can go for it.
> >>
> >> I've found out how browsers check the last modified time on things in the
> >> cache and am trying to get that to work from AIR. Then the next step
> >> would be to figure out how to auto-update the config.xml. Do you know if
> >> there is a way to automate the svnpubsub?
> >>
> >>
> >> -Alex
> >>
> >> On 7/24/14 12:25 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
> >>
> >>> Alex, are we good to go?
> >>>
> >>> If there are no more changes to this draft, I will put out a blog post.
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>>
> >>> On Tue, Jul 22, 2014 at 8:29 AM, Alex Harui <aha...@adobe.com> wrote:
> >>>
> >>>> On 7/22/14 12:59 AM, "Tom Chiverton" <t...@extravision.com> wrote:
> >>>>
> >>>>> Wil https://issues.apache.org/jira/browse/FLEX-34405 be fixed by then ?
> >>>> No, it was reported after we voted to release. Since we got several
> >>>> months into 4.12.1 before it was reported, I don't see it as a reason
> >>>> not
> >>>> to release. Volunteers are welcome, of course, to fix the bug and push
> >>>> a
> >>>> 4.13.1 if they have the time and energy.
> >>>>
> >>>>> What about adl etc ending up in the wrong place sometimes ? That should
> >>>>> definitely be called out as a known issue ?
> >>>> AFAICT, it has been broken for a long time and only discovered recently,
> >>>> so again I wouldn't mess with the release notes and packaging to call it
> >>>> out. Not sure I want to mention known issues that have so far affected
> >>>> few people in the announcement: I would rather focus on positive
> >>>> messages.
> >>>> But if others agree with you I will add it. And again, volunteers are
> >>>> welcome to address this issue as well.
> >>>>
> >>>> -Alex
> >>>>
> >>>>
> >> ______________________________________________________________________
> >> This email has been scanned by the Symantec Email Security.cloud service.
> >> For more information please visit http://www.symanteccloud.com
> >> ______________________________________________________________________
> >>
> > ______________________________________________________________________
> > This email has been scanned by the Symantec Email Security.cloud service.
> > For more information please visit http://www.symanteccloud.com
> > ______________________________________________________________________
> >
>
