311599 - Byte range requests issued by plugins lost when following redirects

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Darin Fisher]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

see the comments in bug 311595...

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 4

[Darin Fisher]

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 :(

Comment 5

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 6

[Darin Fisher]

> > 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?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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).

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

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)

Comment 9

[Darin Fisher]

> 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.

Comment 10

[Darin Fisher]

Oops.. didn't mean to wontfix yet.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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...

Comment 12

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 14

[Benjamin Smedberg]

We're removing byte-range.