Add support for 308 permanent redirects.

Add support for 308 permanent redirects.

See https://datatracker.ietf.org/doc/draft-reschke-http-status-308/

This should not break 308 Resume Incomplete responses, since they
don't have Location headers.

R=willchan@chromium.org
BUG=109012
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=265835

[mmenke, 2012-03-21 18:10:22]

[+Julian], FYI

[julian.reschke, 2012-03-21 20:43:36]

On 2012/03/21 18:10:22, Matt Menke wrote:
> [+Julian], FYI

Looks good, but then I don't know the code base.

The change is a bit more complex than for Firefox, because Firefox right now
treats 301 like 302, thus can treat 308 like 307.

In general, if you have checked all instances of 301 and 307 in the code base,
and made 308 like 301 with respect to permanence, and like 307 with respect to
not changing the method name, all should be fine.

[mmenke, 2012-03-21 21:21:56]

Will:  Don't bother to review this yet.  Looks like we're already using the 308
response code within ChromeOS (GDataUploader), and probably not a good idea to
break that.

[julian.reschke, 2012-03-21 21:26:57]

On 2012/03/21 21:21:56, Matt Menke wrote:
> Will:  Don't bother to review this yet.  Looks like we're already using the
308
> response code within ChromeOS (GDataUploader), and probably not a good idea to
> break that.

OK, if this is serious enough to stop it then I probably should swicth to 309
before it's too late. Feedback appreciated ASAP, as the IETF deadline
approaches, and the Mozilla change just went into -inbound.

[mmenke1, 2012-03-21 21:31:23]

On 2012/03/21 21:26:57, julian.reschke wrote:
> On 2012/03/21 21:21:56, Matt Menke wrote:
> > Will:  Don't bother to review this yet.  Looks like we're already using the
> 308
> > response code within ChromeOS (GDataUploader), and probably not a good idea
to
> > break that.
> 
> OK, if this is serious enough to stop it then I probably should swicth to 309
> before it's too late. Feedback appreciated ASAP, as the IETF deadline
> approaches, and the Mozilla change just went into -inbound.

Sorry, I would have raised this issue earlier if I had been aware of it. 
Changing the status code to 309 sounds good to me.  Looking at our metrics, we
see no 309 responses at all.

[willchan no longer on Chromium, 2012-03-21 21:36:27]

I'm going to review this anyway, since apparently the only thing we need to
change is the response code. I'll withhold approval until we get that
settled. Julian, are you raising this with httpbis? Curse those silly
Google fools for using 308 :P

On Wed, Mar 21, 2012 at 2:31 PM, <mmenke@google.com> wrote:

> On 2012/03/21 21:26:57, julian.reschke wrote:
>
>> On 2012/03/21 21:21:56, Matt Menke wrote:
>> > Will:  Don't bother to review this yet.  Looks like we're already using
>> the
>> 308
>> > response code within ChromeOS (GDataUploader), and probably not a good
>> idea
>>
> to
>
>> > break that.
>>
>
>  OK, if this is serious enough to stop it then I probably should swicth to
>> 309
>> before it's too late. Feedback appreciated ASAP, as the IETF deadline
>> approaches, and the Mozilla change just went into -inbound.
>>
>
> Sorry, I would have raised this issue earlier if I had been aware of it.
> Changing the status code to 309 sounds good to me.  Looking at our
> metrics, we
> see no 309 responses at all.
>
>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>

[willchan no longer on Chromium, 2012-03-21 21:36:43]

Er, and yes, 309 is fine by me.

On Wed, Mar 21, 2012 at 2:36 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> I'm going to review this anyway, since apparently the only thing we need
> to change is the response code. I'll withhold approval until we get that
> settled. Julian, are you raising this with httpbis? Curse those silly
> Google fools for using 308 :P
>
> On Wed, Mar 21, 2012 at 2:31 PM, <mmenke@google.com> wrote:
>
>> On 2012/03/21 21:26:57, julian.reschke wrote:
>>
>>> On 2012/03/21 21:21:56, Matt Menke wrote:
>>> > Will:  Don't bother to review this yet.  Looks like we're already
>>> using the
>>> 308
>>> > response code within ChromeOS (GDataUploader), and probably not a good
>>> idea
>>>
>> to
>>
>>> > break that.
>>>
>>
>>  OK, if this is serious enough to stop it then I probably should swicth
>>> to 309
>>> before it's too late. Feedback appreciated ASAP, as the IETF deadline
>>> approaches, and the Mozilla change just went into -inbound.
>>>
>>
>> Sorry, I would have raised this issue earlier if I had been aware of it.
>> Changing the status code to 309 sounds good to me.  Looking at our
>> metrics, we
>> see no 309 responses at all.
>>
>>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>>
>
>

[julian.reschke, 2012-03-21 21:47:26]

On 2012-03-21 22:31, mmenke@google.com wrote:
> On 2012/03/21 21:26:57, julian.reschke wrote:
>> On 2012/03/21 21:21:56, Matt Menke wrote:
>> > Will: Don't bother to review this yet. Looks like we're already
>> using the
>> 308
>> > response code within ChromeOS (GDataUploader), and probably not a
>> good idea
> to
>> > break that.
>
>> OK, if this is serious enough to stop it then I probably should swicth
>> to 309
>> before it's too late. Feedback appreciated ASAP, as the IETF deadline
>> approaches, and the Mozilla change just went into -inbound.
>
> Sorry, I would have raised this issue earlier if I had been aware of it.
> Changing the status code to 309 sounds good to me. Looking at our
> metrics, we
> see no 309 responses at all.
>
> http://codereview.chromium.org/9816011/

OK.

So this has been in IETF LC for four weeks, and in informal LC for 
another few weeks. I realize it's not your fault, but the spec *has* 
been approved already.

There's a slim chance to stop and change it, but it would be *extremely* 
useful if you could send feedback explaining the problem to the HTTP WG 
*and* to iesg@ietf.org.

(note that the Mozilla code change just went it, so we really shouldn't 
waste any time here)

Best regards, Julian

PS: as you have the data, it would be awesome if you could check whether 
there would be a problem using 306, which would be nice as 306 would be 
to 301 what 307 is to 302.

[willchan no longer on Chromium, 2012-03-21 21:58:26]

306 sees basically 0 use.

On Wed, Mar 21, 2012 at 2:47 PM, Julian Reschke <
julian.reschke@googlemail.com> wrote:

> On 2012-03-21 22:31, mmenke@google.com wrote:
>
>> On 2012/03/21 21:26:57, julian.reschke wrote:
>>
>>> On 2012/03/21 21:21:56, Matt Menke wrote:
>>> > Will: Don't bother to review this yet. Looks like we're already
>>> using the
>>> 308
>>> > response code within ChromeOS (GDataUploader), and probably not a
>>> good idea
>>>
>> to
>>
>>> > break that.
>>>
>>
>>  OK, if this is serious enough to stop it then I probably should swicth
>>> to 309
>>> before it's too late. Feedback appreciated ASAP, as the IETF deadline
>>> approaches, and the Mozilla change just went into -inbound.
>>>
>>
>> Sorry, I would have raised this issue earlier if I had been aware of it.
>> Changing the status code to 309 sounds good to me. Looking at our
>> metrics, we
>> see no 309 responses at all.
>>
>>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>>
>
> OK.
>
> So this has been in IETF LC for four weeks, and in informal LC for another
> few weeks. I realize it's not your fault, but the spec *has* been approved
> already.
>
> There's a slim chance to stop and change it, but it would be *extremely*
> useful if you could send feedback explaining the problem to the HTTP WG
> *and* to iesg@ietf.org.
>
> (note that the Mozilla code change just went it, so we really shouldn't
> waste any time here)
>
> Best regards, Julian
>
> PS: as you have the data, it would be awesome if you could check whether
> there would be a problem using 306, which would be nice as 306 would be to
> 301 what 307 is to 302.
>
>

[julian.reschke, 2012-03-21 22:48:28]

On 2012-03-21 22:21, mmenke@chromium.org wrote:
> Will: Don't bother to review this yet. Looks like we're already using
> the 308
> response code within ChromeOS (GDataUploader), and probably not a good
> idea to
> break that.
>
> http://codereview.chromium.org/9816011/

Preliminary feedback from the IESG says that it would be unwise to 
change the status code post-approval.

Thus the options are to go back to IETF Last Call, or to investigate 
whether ChromeOS can migrate to a different status code (and this time 
register it).

Best regards, Julian

[willchan no longer on Chromium, 2012-03-21 22:51:24]

I'll loop in the relevant folks Google-side.

On Wed, Mar 21, 2012 at 3:48 PM, Julian Reschke <
julian.reschke@googlemail.com> wrote:

> On 2012-03-21 22:21, mmenke@chromium.org wrote:
>
>> Will: Don't bother to review this yet. Looks like we're already using
>> the 308
>> response code within ChromeOS (GDataUploader), and probably not a good
>> idea to
>> break that.
>>
>>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>>
>
> Preliminary feedback from the IESG says that it would be unwise to change
> the status code post-approval.
>
> Thus the options are to go back to IETF Last Call, or to investigate
> whether ChromeOS can migrate to a different status code (and this time
> register it).
>
> Best regards, Julian
>
>

[julian.reschke, 2012-03-21 22:58:02]

On 2012-03-21 23:51, William Chan (陈智昌) wrote:
> I'll loop in the relevant folks Google-side.
> ...

Thanks!

[julian.reschke, 2012-03-23 09:39:24]

On 2012-03-21 23:51, William Chan (陈智昌) wrote:
> I'll loop in the relevant folks Google-side.
> ...

Note that I need a plan how to proceed as of next Monday...

(The spec is waiting to enter the RFC Editor queue, and also Firefox 
trunk now has the status code implemented).

With respect to the current use of 308: this either should be documented 
and registered, or done in a different way (such as with 300 and an 
extension header). Please do *not* simply move to 309 because then the 
same problem will likely recur again.

Best regards, Julian

[willchan no longer on Chromium, 2012-03-23 15:24:39]

We're discussing the matter internally. We'll get back to you later today.
Cheers.

On Fri, Mar 23, 2012 at 2:39 AM, Julian Reschke <
julian.reschke@googlemail.com> wrote:

> On 2012-03-21 23:51, William Chan (陈智昌) wrote:
>
>> I'll loop in the relevant folks Google-side.
>> ...
>>
>
> Note that I need a plan how to proceed as of next Monday...
>
> (The spec is waiting to enter the RFC Editor queue, and also Firefox trunk
> now has the status code implemented).
>
> With respect to the current use of 308: this either should be documented
> and registered, or done in a different way (such as with 300 and an
> extension header). Please do *not* simply move to 309 because then the same
> problem will likely recur again.
>
> Best regards, Julian
>

[cbentzel, 2012-03-23 15:59:21]

The plan is to migrate the service to use a different status code or other
signaling mechanism.

So, no requested changes to the current document (and Firefox's
implementation).

This patch for Chromium may need to be delayed until the service changes,
however.

Thanks for providing suggestions for how to adjust the service going into
the future.

On Fri, Mar 23, 2012 at 11:24 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> We're discussing the matter internally. We'll get back to you later today.
> Cheers.
>
>
> On Fri, Mar 23, 2012 at 2:39 AM, Julian Reschke <
> julian.reschke@googlemail.com> wrote:
>
>> On 2012-03-21 23:51, William Chan (陈智昌) wrote:
>>
>>> I'll loop in the relevant folks Google-side.
>>> ...
>>>
>>
>> Note that I need a plan how to proceed as of next Monday...
>>
>> (The spec is waiting to enter the RFC Editor queue, and also Firefox
>> trunk now has the status code implemented).
>>
>> With respect to the current use of 308: this either should be documented
>> and registered, or done in a different way (such as with 300 and an
>> extension header). Please do *not* simply move to 309 because then the same
>> problem will likely recur again.
>>
>> Best regards, Julian
>>
>
>

[julian.reschke, 2012-03-23 16:09:10]

On 2012-03-23 16:59, Chris Bentzel wrote:
> The plan is to migrate the service to use a different status code or
> other signaling mechanism.
>
> So, no requested changes to the current document (and Firefox's
> implementation).
>
> This patch for Chromium may need to be delayed until the service
> changes, however.
>
> Thanks for providing suggestions for how to adjust the service going
> into the future.
> ...

Thanks a lot!

Best regards, Julian

[cbentzel, 2012-03-26 17:32:12]

As discussed, this will need to go into the cryogenic chamber for a little
while.

[cbentzel, 2012-08-01 22:24:57]

The 308 response code is no longer being used by browser-based clients of
the Google service, so we should be able to safely land this change in
Chromium now.

On Mon, Mar 26, 2012 at 1:32 PM, <cbentzel@chromium.org> wrote:

> As discussed, this will need to go into the cryogenic chamber for a little
> while.
>
>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>

[mmenke, 2012-08-01 22:28:14]

There's still code in ChromeOS to handle it.
http://code.google.com/p/chromium/source/search?q=HTTP_RESUME_INCOMPLETE&orig...


On Wed, Aug 1, 2012 at 6:24 PM, Chris Bentzel <cbentzel@chromium.org> wrote:

> The 308 response code is no longer being used by browser-based clients of
> the Google service, so we should be able to safely land this change in
> Chromium now.
>
>
> On Mon, Mar 26, 2012 at 1:32 PM, <cbentzel@chromium.org> wrote:
>
>> As discussed, this will need to go into the cryogenic chamber for a little
>> while.
>>
>>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>>
>
>

[cbentzel, 2012-08-01 22:45:16]

OK, that should be changeable now.

On Wed, Aug 1, 2012 at 6:28 PM, Matt Menke <mmenke@chromium.org> wrote:

> There's still code in ChromeOS to handle it.
>
http://code.google.com/p/chromium/source/search?q=HTTP_RESUME_INCOMPLETE&orig...
>
>
> On Wed, Aug 1, 2012 at 6:24 PM, Chris Bentzel <cbentzel@chromium.org>wrote:
>
>> The 308 response code is no longer being used by browser-based clients of
>> the Google service, so we should be able to safely land this change in
>> Chromium now.
>>
>>
>> On Mon, Mar 26, 2012 at 1:32 PM, <cbentzel@chromium.org> wrote:
>>
>>> As discussed, this will need to go into the cryogenic chamber for a
>>> little
>>> while.
>>>
>>>
http://codereview.chromium.**org/9816011/<http://codereview.chromium.org/9816...
>>>
>>
>>
>

[mmenke, 2014-04-23 15:45:28]

Will:  PTAL.

https://codereview.chromium.org/9816011/diff/57002/net/http/http_response_hea...
File net/http/http_response_headers.cc (right):

https://codereview.chromium.org/9816011/diff/57002/net/http/http_response_hea...
net/http/http_response_headers.cc:1027: // future references ... SHOULD use one
of the returned URIs."
Is there a non-expired doc I should be pointing to instead?  I can't seem to
find one.

[julian.reschke, 2014-04-23 16:04:36]

On 23.04.2014 17:45, mmenke@chromium.org wrote:
> Will:  PTAL.
>
>
>
https://codereview.chromium.org/9816011/diff/57002/net/http/http_response_hea...
>
> File net/http/http_response_headers.cc (right):
>
>
https://codereview.chromium.org/9816011/diff/57002/net/http/http_response_hea...
>
> net/http/http_response_headers.cc:1027: // future references ... SHOULD
> use one of the returned URIs."
> Is there a non-expired doc I should be pointing to instead?  I can't
> seem to find one.

It isn't expired, as it's approved and in the RFC publication queue. If 
you can wait ~2 more weeks, it'll have an RFC number.

> https://codereview.chromium.org/9816011/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[willchan no longer on Chromium, 2014-04-23 22:24:02]

+rvargas as an fyi

https://codereview.chromium.org/9816011/diff/57002/net/url_request/url_reques...
File net/url_request/url_request_unittest.cc (right):

https://codereview.chromium.org/9816011/diff/57002/net/url_request/url_reques...
net/url_request/url_request_unittest.cc:6048: }
Can you also verify the response code just to show that it's not getting munged
somehow?

[willchan no longer on Chromium, 2014-04-23 22:24:12]

lgtm

[willchan no longer on Chromium, 2014-04-23 22:24:29]

Very excited to see this finally getting in.

[mmenke, 2014-04-24 00:13:46]

Thanks for the review!

https://codereview.chromium.org/9816011/diff/57002/net/url_request/url_reques...
File net/url_request/url_request_unittest.cc (right):

https://codereview.chromium.org/9816011/diff/57002/net/url_request/url_reques...
net/url_request/url_request_unittest.cc:6048: }
On 2014/04/23 22:24:03, willchan wrote:
> Can you also verify the response code just to show that it's not getting
munged
> somehow?

Good idea, done.

[mmenke, 2014-04-24 00:13:54]

The CQ bit was checked by mmenke@chromium.org

[commit-bot: I haz the power, 2014-04-24 00:15:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mmenke@chromium.org/9816011/77002

[commit-bot: I haz the power, 2014-04-24 03:32:41]

Change committed as 265835