Byte range requests issued by plugins lost when following redirects This is an off-shoot of bug 311595. Basically, if a plugin (like adobe acrobat) issues a range request, and that request is redirected, then the Range header is not applied to the new HTTP request. As a result, the optimization of issuing a range header is completely lost. I don't know how common this shows up on the web, but it seems like it'd be pretty annoying when it does. We probably want to patch nsPluginHostImpl.cpp in a manner similar to how nsIncrementalDownload.cpp is being patched in bug 311595.

Frankly, I think the HTTP redirect code should just carry this header over instead of making all consumers handle it....

see the comments in bug 311595...

maybe what we should do is offer a variant of setRequestHEader that specifies whether to copy that header to redirected channels.

but since request headers are merged into the same string, we'd then need to keep track of which sub-parts of request headers are to be copied and which are not to be copied :(

> see the comments in bug 311595... I read those the first time through. ;) I'm not saying copy all headers, but the Range header specifically.

> > see the comments in bug 311595... > > I read those the first time through. ;) > > I'm not saying copy all headers, but the Range header specifically. Boris: So what is your response to 311595#c9?

If we're seriously concerned about that, we should wontfix this bug, since all those concerns apply to redirects no matter what the consumer of the redirect is, unless we control the server completely (as with update).

so in response to bug 311595 comment 9: couldn't, for the login case, the server also decide to serve the login page directly under the requested URL? the client can never be 100% sure what it will get... and sending a range header with a POST request seems rather unusual to me. (if we do this, we should consider also forwarding If-Match and If-Unmodified-Since)

> If we're seriously concerned about that, we should wontfix this bug, since all > those concerns apply to redirects no matter what the consumer of the redirect > is, unless we control the server completely (as with update). Very true. > so in response to bug 311595 comment 9: couldn't, for the login case, the > server also decide to serve the login page directly under the requested URL? Yes. And, a 200 response is always valid for a Range request. > the client can never be 100% sure what it will get... and sending a range > header with a POST request seems rather unusual to me. True. > (if we do this, we should consider also forwarding If-Match and > If-Unmodified-Since) Agreed. We should figure out what IE does. It'd probably be easiest to test Acrobat Reader.

Oops.. didn't mean to wontfix yet.

> If we're seriously concerned about that, we should wontfix this bug, since all > those concerns apply to redirects no matter what the consumer of the redirect > is, unless we control the server completely (as with update). I don't agree. Consumers that are browsers loading pages can usually do something useful with a redirect to a login page. For all other consumers --- Acrobat Reader loading PDF data, <img> loading an image, <video> loading a video, anyone doing XMLHttpRequest --- getting back a login page instead (or in general, a "different resource") is completely useless and broken. So I think we should at least carry Range requests across redirects for consumers that aren't browsers loading content into a docshell. I guess consumers can implement this themselves using OnChannelRedirect, so that's what I'll be doing...

> I don't agree. Don't agree with the conclusion, or don't agree with the premise? _I_ don't agree with the premise, for what it's worth. I think we should just fix this bug. If we want to be safe(r) in terms of the things Darin was worrying about we can not copy the header for document requests or something.

I don't agree that these concerns apply equally no matter what the consumer is. I agree it would make sense to special-case loads into docshells.

We're removing byte-range.