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.

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.

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.

neeti, I am taking this one.

Fixed checked in.