Closed Bug 714302 Opened 13 years ago Closed 12 years ago

add support for HTTP status code 308

Categories

(Core :: Networking, enhancement)

Product:
Core
Component:
Networking
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla14

People

(Reporter: julian.reschke, Assigned: julian.reschke)

References

(
URL
)

Details

(Keywords: dev-doc-complete, Whiteboard: [secr:dveditz])

Attachments

(1 file)

Proposed patch, incl updated test cases
3.97 KB, patch
mcmanus
: review+
Details | Diff | Splinter Review 
http://tools.ietf.org/html/draft-reschke-http-status-308 defines a permanent variant of status code 307 (which is defined to be temporary redirect).

Opening this bug for tracking purposes (and to have a place to attach a potential patch to).
OS: Android → All
Comment on attachment 585433 [details] [diff] [review]
Proposed patch, incl updated test cases

Review of attachment 585433 [details] [diff] [review]:
-----------------------------------------------------------------

I'm fine with the code, r=mcmanus.

can you add it to the sec-review you are doing for the related redirect issue? It would be good to have that done before checking in - sometimes sec-team thinks much harder about redirect nasties than I can :)
Attachment #585433 - Flags: review?(mcmanus) → review+
We can already cache "307 Temporary Redirect". How are the semantics of 308 different than "307 Temporary Redirect" with "cache forever" response headers? Is it the case that, for Gecko, there should be no difference, but for other applications, there might be a difference?

Recently, we've implemented redirect-like features (e.g. SPDY's Alternate-Protocol, HSTS) in a way that acknowledges that it isn't a great idea to blindly honor (permanent) redirects requested by the server, especially when the redirect was returned in insecure response (one not protected by SSL). I think it actually might be worth revisiting how we cache 30x responses in our HTTP caches, to see if it is in line with this (relatively new) line of reasoning. It seems like there may well be an inconsistency here that should be resolved one in some way. Depending on the results of that, we may need to suggest improvements to the HTTP, SPDY, and HSTS spec authors.

I could see some line of reasoning that says that the whole idea of "permanent" redirects is ungood for security, at least in browsers, and so we shouldn't trust redirects (permanent or temporary) beyond a certain amount of time--i.e. there should be no difference between permanent and temporary redirects in web browsers. Does it make sense to trust permanent redirects from http[s]://example.org/ to http[s]://attacker.com on subsequent connections just because the current connection was compromised? Does it make sense to rewrite somebody's bookmarks from http[s]://paypal.com to http[s]://paypal.com.attacker.com in such a scenerio? Does it make sense for Google to permanently de-list http://example.org because it once received a "permanent" redirect from that site to http://attacker.com? It seems wrong to amplify temporary attacks into permanent ones. But, there are also legit uses of permanent redirects.

(This all applies to non-SSL HTTP *and* HTTPS, when we take into account the fact that not every certificate (and not every CA in our CA root store) is trustworthy.)

If we treat 308 responses exactly like 307 responses, then this devolves for us into the more general problem of HTTP cache poisoning. So, AFAICT, supporting the 308 status code itself is not really problematic, except insofar as it promotes the idea of "permanent" redirects actually being permanent in the eyes of the UA.
(In reply to Brian Smith (:bsmith) from comment #4)
> We can already cache "307 Temporary Redirect". How are the semantics of 308
> different than "307 Temporary Redirect" with "cache forever" response
> headers? Is it the case that, for Gecko, there should be no difference, but
> for other applications, there might be a difference?

We discussed 307 with cache control metadata in the HTTPbis WG and decided that it doesn't *excatly* do what we want, thus the proposal for 308.

The difference described by the specs is exactly the same as between 301 and 302:

"The target resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references returned by the server, where possible."

as opposed to

"The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the effective request URI for future requests."

> Recently, we've implemented redirect-like features (e.g. SPDY's
> Alternate-Protocol, HSTS) in a way that acknowledges that it isn't a great
> idea to blindly honor (permanent) redirects requested by the server,
> especially when the redirect was returned in insecure response (one not
> protected by SSL). I think it actually might be worth revisiting how we
> cache 30x responses in our HTTP caches, to see if it is in line with this
> (relatively new) line of reasoning. It seems like there may well be an

Yes.

> inconsistency here that should be resolved one in some way. Depending on the
> results of that, we may need to suggest improvements to the HTTP, SPDY, and
> HSTS spec authors.

Well, the semantics of 301/302 with respect to this point haven't changed for more than 10 years; so I doubt that we could agree in HTTPbis to change *that*. Note that it's fine if a specific client doesn't trust the "permanence" bit; if we phrase that as a potential security issue it would be good to provide feedback on the HTTPbis mailing list...

> I could see some line of reasoning that says that the whole idea of
> "permanent" redirects is ungood for security, at least in browsers, and so
> we shouldn't trust redirects (permanent or temporary) beyond a certain
> amount of time--i.e. there should be no difference between permanent and
> temporary redirects in web browsers. Does it make sense to trust permanent
> redirects from http[s]://example.org/ to http[s]://attacker.com on
> subsequent connections just because the current connection was compromised?
> Does it make sense to rewrite somebody's bookmarks from http[s]://paypal.com
> to http[s]://paypal.com.attacker.com in such a scenerio? Does it make sense
> for Google to permanently de-list http://example.org because it once
> received a "permanent" redirect from that site to http://attacker.com? It
> seems wrong to amplify temporary attacks into permanent ones. But, there are
> also legit uses of permanent redirects.
> 
> (This all applies to non-SSL HTTP *and* HTTPS, when we take into account the
> fact that not every certificate (and not every CA in our CA root store) is
> trustworthy.)
> 
> If we treat 308 responses exactly like 307 responses, then this devolves for
> us into the more general problem of HTTP cache poisoning. So, AFAICT,
> supporting the 308 status code itself is not really problematic, except
> insofar as it promotes the idea of "permanent" redirects actually being
> permanent in the eyes of the UA.

Not anymore than 301 already does. I just completes the set of redirects; it doesn't add anything totally new (the main reason for the proposal is that browsers never implemented 301 as defined, so the spec had to relax *that* definition).
need to schedule a secteam review
Whiteboard: [secr:curtisk]
(In reply to Curtis Koenig [:curtisk] from comment #6)
> need to schedule a secteam review

Not sure what kind of review you have in mind. As Firefox doesn't distinguish permanent from temporary redirects, 308 is doing exactly what 307 does already. (Similarly to 301 vs 302)
(In reply to Julian Reschke from comment #7) 
> Not sure what kind of review you have in mind. As Firefox doesn't
> distinguish permanent from temporary redirects, 308 is doing exactly what
> 307 does already. (Similarly to 301 vs 302)

Is this not the bug that was suggested for review along with XHR review, subsequently said review was canceled. I also think there is general concern in some members of secteam over any HTTP header changes.
(In reply to Curtis Koenig [:curtisk] from comment #8)
> (In reply to Julian Reschke from comment #7) 
> > Not sure what kind of review you have in mind. As Firefox doesn't
> > distinguish permanent from temporary redirects, 308 is doing exactly what
> > 307 does already. (Similarly to 301 vs 302)
> 
> Is this not the bug that was suggested for review along with XHR review,
> subsequently said review was canceled. I also think there is general concern
> in some members of secteam over any HTTP header changes.

Yes, it is that bug; I didn't think we need review in the first place, but it seemed to be easy to add it to other review we were going to do.

So does sec-review imply a telco, or is this just so somebody reviews the change? (brian did that above).
(In reply to Julian Reschke from comment #9)
> ...
> So does sec-review imply a telco, or is this just so somebody reviews the
> change? (brian did that above).

I see that Brian has taken the discussion to the dev-tech-network mailing list. Thanks!
I think between dveditz, tanvi & imelven a review can be done without having a telco on this.
Informal Last Call for comments on the specification, ending 2012-01-29: <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0038.html>
(In reply to Curtis Koenig [:curtisk] from comment #11)
> I think between dveditz, tanvi & imelven a review can be done without having
> a telco on this.

is this in progress?

I think we want to proceed with this - its destined for standards approval, has no real downside for us, and would allow other apps to use it freely if we understood the semantics (even if we just map it to something we already do). 

I don't want to be the laggard browser - this kind of patch submission from someone well invested in the standards process should be easy to take.
IETF Last Call just started; see <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0502.html>
Assignee: nobody → julian.reschke
Note that IETF Last Call ends on March 16. So "now" would be the time to make the change if Mozilla wants to provide implementation feedback before the Last Call ends.
since this is related to the other 308 bug changing secr to dveditz
Whiteboard: [secr:curtisk] → [secr:dveditz]
...there should be only one bug related to status 308 (this one).
Approved for publication as (Experimental) RFC: <https://datatracker.ietf.org/doc/draft-reschke-http-status-308/>
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/8e9c49a39833
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Hi folks:  I was just made aware of this change.  Unfortunately, several Google sites have been using this status code for a couple of years in a way that's incompatible with the RFC.  We are working to fix this now.  In the mean time, could you delay his change until our sites have been updated?  We expect this to take a few weeks.

Thanks!
(In reply to Michael Yu from comment #21)
> Hi folks:  I was just made aware of this change.  Unfortunately, several
> Google sites have been using this status code for a couple of years in a way
> that's incompatible with the RFC.  We are working to fix this now.  In the

How so? Script that assumes the redirect isn't followed? Is a Location header field in the response?

> mean time, could you delay his change until our sites have been updated?  We
> expect this to take a few weeks.
> 
> Thanks!

The change would go into the "aurora" branch in ~4 weeks and into "beta" in ~10 weeks. Is that sufficient?
(In reply to Michael Yu from comment #21)
> Hi folks:  I was just made aware of this change.  Unfortunately, several
> Google sites have been using this status code for a couple of years in a way
> that's incompatible with the RFC.  We are working to fix this now.  In the
> mean time, could you delay his change until our sites have been updated?  We
> expect this to take a few weeks.
> 
> Thanks!

Hi Michael - I really appreciate you posting to this bug. can you explain the mismatch in detail?

This code is 15 or 16 weeks away from being on a release channel. Does that comfortably fit within your time-to-fix target?
Hi Julian and Patrick:  Thanks for the responses!

308 is used in our resumable upload protocol.  Here's a description of the protocol used in Google Data APIs: http://code.google.com/apis/gdata/docs/resumable_upload.html.  Our web apps use a similar protocol.

We do not send a "Location" header with the 308 response.  Would Firefox continue to behave as before without this header?

Either way, 15 weeks should be enough time to comfortably update our sites.
(In reply to Michael Yu from comment #24)
> Hi Julian and Patrick:  Thanks for the responses!
> 
> 308 is used in our resumable upload protocol.  Here's a description of the
> protocol used in Google Data APIs:
> http://code.google.com/apis/gdata/docs/resumable_upload.html.  Our web apps
> use a similar protocol.
> 
> We do not send a "Location" header with the 308 response.  Would Firefox
> continue to behave as before without this header?

I believe so, but I haven't tested it yet. Should be easy to verify with the nightly build.

> Either way, 15 weeks should be enough time to comfortably update our sites.

Sounds good!
(In reply to Michael Yu from comment #24)
> Hi Julian and Patrick:  Thanks for the responses!
> 
> 308 is used in our resumable upload protocol. 

Thanks!


> We do not send a "Location" header with the 308 response.  Would Firefox
> continue to behave as before without this header?
> 

I think so - I just tested a 308 response with no location and it displayed just fine. You can test your use case using a build from nightly.mozilla.org

> Either way, 15 weeks should be enough time to comfortably update our sites.


great.. we can back this out fairly late in the game, so if it gets within a few weeks to release time for FF14 and you've got a problem let me know.
I've updated the documentation:
https://developer.mozilla.org/en/HTTP/HTTP_response_codes#308
and
https://developer.mozilla.org/en/Firefox_14_for_developers#section_1

If you do back it out, don't forget to add dev-doc-needed in the back-out bug (or to flip it here) so that we can update the doc accordingly (especially Firefox 15 for developers)
Keywords: dev-doc-complete
(In reply to Jean-Yves Perrier [:teoli] from comment #27)
> I've updated the documentation:
> https://developer.mozilla.org/en/HTTP/HTTP_response_codes#308

Nit: it's not "HTTPbis" (but "draft-reschke-http-status-308"), and the link should go to http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-07.html.

(I know that it's a Wiki, but the new browserid login doesn't seem to work for me right now)
Julian: thank you. I fixed it.

A small question: could you confirm that the difference between 301/302 and 307/308 is that with 307/308 the UA is not allowed to changed the method used to access the page (that is if the original request is a POST, the second must be a POST with the same content)?

Also, with all the evolution of HTTP that happens nowadays it would be cool if you write an article about them: what is httpbis, what evolutions are in progress, where and why. What are the status of these evolutions and the next steps. Hacks.mozilla.org would be a cool place to publish such an article.
(In reply to Jean-Yves Perrier [:teoli] from comment #29)
> Julian: thank you. I fixed it.
> 
> A small question: could you confirm that the difference between 301/302 and
> 307/308 is that with 307/308 the UA is not allowed to changed the method
> used to access the page (that is if the original request is a POST, the
> second must be a POST with the same content)?

Yes. 301 and 302 allow rewriting POST to GET. (And only that!)

> Also, with all the evolution of HTTP that happens nowadays it would be cool
> if you write an article about them: what is httpbis, what evolutions are in
> progress, where and why. What are the status of these evolutions and the
> next steps. Hacks.mozilla.org would be a cool place to publish such an
> article.

Noted :-)
Hi Julian and Patrick:  I downloaded the nightly, and it appears that 308s without Location headers work as they did before (I did run into another issue with connections timing out, but this appears to be unrelated to the 308s).  At this point, I don't anticipate needing more time, but I'll let you know if we run into any problems.  Thanks again for all your help and flexibility!
(In reply to Michael Yu from comment #31)
> Hi Julian and Patrick:  I downloaded the nightly, and it appears that 308s
> without Location headers work as they did before (I did run into another
> issue with connections timing out, but this appears to be unrelated to the
> 308s).  At this point, I don't anticipate needing more time, but I'll let
> you know if we run into any problems.  Thanks again for all your help and
> flexibility!

awesome - if the other issue looks like a real bug can you email it to me at pmcmanus@mozilla.com ? I've got a todo queue to add it to.
Depends on: 757284
No longer depends on: 757284
Flags: sec-review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: