Byte range requests issued by plugins lost when following redirects

RESOLVED WONTFIX

Status

()

Core
Plug-ins
--
minor
RESOLVED WONTFIX
13 years ago
a year ago

People

(Reporter: Darin Fisher, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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....
Flags: blocking1.9a2?
maybe what we should do is offer a variant of setRequestHEader that specifies whether to copy that header to redirected channels.
(Reporter)

Comment 4

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

Comment 6

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

Comment 9

12 years ago
> 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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 10

12 years ago
Oops.. didn't mean to wontfix yet.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Reporter)

Updated

12 years ago
Assignee: darin → nobody
Status: REOPENED → NEW
Flags: blocking1.9a2? → blocking1.9-
> 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.

Comment 14

a year ago
We're removing byte-range.
Status: NEW → RESOLVED
Last Resolved: 12 years agoa year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.