Closed Bug 77775 Opened 23 years ago Closed 23 years ago

Multiple byte range requests do not work

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla0.9.1

People

(Reporter: serhunt, Assigned: dougt)

References

Details

Working on implementation of range requests for plugins (bug 53363) I noticed 
that if I set a header to request more than one range, say, 
Range: bytes=500-700,601-999 the data which starts to come upon the request is 
corrupted.

I cannot provide with a test case since 53363 is not fixed yet, I do my testing 
just settings things manually  in the debugger.

Cc'ing Liz from Adobe as she will be able to help understand how exactly plugins 
want to get the multiple ranges back.
Setting priority, platform and dependency.
Depends on: 53363
OS: Windows NT → All
Priority: -- → P2
Hardware: PC → All
I am not sure exactly what you are asking for but let me try to answer
what I think the question is:

Acrobat will ask for multiple ranges of bytes at a time -- sometimes we
will ask the browser for over a hundred range requests in one swoop.  


We really don't have any expectation on the receiving end as to what
order those ranges come in, or even if the range that is delivered
to us by the browser exactly equals a range that we asked for.
For example, if we ask for ranges 100-200, 400-500, it is OK to give
us back 300-400, 100 -200, and then 400-500.    The browser can
give us back multiple ranges in one shot, or a range at a time
(though that is probably inefficient since we are doing interprocess
communication between the apps to pass the data back and forth). 


We have code on the Acrobat side to deal with ranges out of order
and not exactly what we asked for.  You send them in a way
that is easy and clean for you to code. 

We would prefer them in approximately the order that we asked for
them, since the order reflects our need for those bytes, but it
is not critical. 

On the other hand, I have learned ONE lesson from the school of hard
knocks:  It is much better to give us a lot of bytes at once in
a range (e.g. 1-16K at a time), then a bunch of small ranges.
Nav 4.X gives us 1-16K at a time.  Unfortunately, right now, Mac IE 5
gives us lots of teeny-weeny ranges, come as small as 16 bytes! 
Unfortunately, this causes Acrobat to spend a lot of time in its
cache management code, which can cause delays to the user.  For example, one
very complex PDF file takes 30 seconds to draw  with Nav 4.X on my
Mac and 6 minutes to draw with Mac IE 5 due to this problem.

If you would like a copy of our Netscape plug-in souces and project files to
see exactly what we do with these ranges, I can send that to you.
I have given the sources and project files to at least one other
person in Netscape (John Gaunt), to someone in Sun and to Microsoft. 
There really isn't anything proprietary in the code for our plug-in
(since Acrobat runs as a separate app, the "family jewels" are not
in NS plug-in). 
Gagan -- please see 53363 for some answers to questions from Andrei.
Neeti: can you take this? The processing of multipart/byte-range would be pretty
similar to multipart/mixed. I think the changes in necko would be fairly small.
Let me know if you need any help with this.
Assignee: gagan → neeti
Target Milestone: --- → mozilla0.9.2
Another thing I mentioned when talking to Gagan, when the requested range comes 
back the aSourceOffset parameter is always zero, although the data itself seems 
to be ok. I think this should also be fixed otherwise in case of multiple
ranges (I guess the order they come is not guaranteed) the client will not know 
what part this particular range is from.
Reshuffling dependency.
No longer depends on: 53363
Blocks: 53363
neeti, I am taking this one.
Assignee: neeti → dougt
Target Milestone: mozilla0.9.2 → mozilla0.9.1
Depends on: 81384
Fixed checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.