Multiple byte range requests do not work

RESOLVED FIXED in mozilla0.9.1

Status

()

Core
Networking
P2
normal
RESOLVED FIXED
17 years ago
15 years ago

People

(Reporter: av (gone), Assigned: dougt)

Tracking

Trunk
mozilla0.9.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Setting priority, platform and dependency.
Depends on: 53363
OS: Windows NT → All
Priority: -- → P2
Hardware: PC → All

Comment 2

17 years ago
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). 

Comment 3

17 years ago
Gagan -- please see 53363 for some answers to questions from Andrei.

Comment 4

17 years ago
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

Updated

17 years ago
Target Milestone: --- → mozilla0.9.2
(Reporter)

Comment 5

17 years ago
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.
(Reporter)

Comment 6

17 years ago
Reshuffling dependency.
No longer depends on: 53363
(Reporter)

Updated

17 years ago
Blocks: 53363
(Assignee)

Comment 7

17 years ago
neeti, I am taking this one.
Assignee: neeti → dougt
Target Milestone: mozilla0.9.2 → mozilla0.9.1
(Assignee)

Updated

17 years ago
Depends on: 81384
(Assignee)

Comment 8

17 years ago
Fixed checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

15 years ago
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.