New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add "HTTP status code headers" #1830

Open
crucifyer opened this Issue Aug 24, 2015 · 11 comments

Comments

Projects
None yet
10 participants
@crucifyer

ex) 307 temporary redirect
so many new status codes
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

@Ugoku

This comment has been minimized.

Show comment
Hide comment
@Ugoku

Ugoku Aug 25, 2015

Contributor

-1
This is a server feature, not a browser feature.

Contributor

Ugoku commented Aug 25, 2015

-1
This is a server feature, not a browser feature.

@Ugoku

This comment has been minimized.

Show comment
Hide comment
@Ugoku

Ugoku Aug 25, 2015

Contributor

Hm okay, but what would this data do on caniuse? A lone 301 or 308 won't do anything without also sending a Location header. A search bot will differentiate between a 301/308 and a 302/307, but what should a browser do?

In other words, let's say caniuse implements a compatibility table for 307 headers. What should the table show according to you?

Contributor

Ugoku commented Aug 25, 2015

Hm okay, but what would this data do on caniuse? A lone 301 or 308 won't do anything without also sending a Location header. A search bot will differentiate between a 301/308 and a 302/307, but what should a browser do?

In other words, let's say caniuse implements a compatibility table for 307 headers. What should the table show according to you?

@crucifyer

This comment has been minimized.

Show comment
Hide comment
@crucifyer

crucifyer Aug 25, 2015

keyword 308
unsupported old browser version result.
I think this good information, so I suggested.

if ignored, its ok.
please, close thread.

thank you.

keyword 308
unsupported old browser version result.
I think this good information, so I suggested.

if ignored, its ok.
please, close thread.

thank you.

@collinanderson

This comment has been minimized.

Show comment
Hide comment
@collinanderson

collinanderson Jan 10, 2016

+1
I'm curious what the browser support is for the new 307 and 308 status codes. If the browser correctly redirects to the new location while preserving the method (like POST), then the browser has the feature implemented correctly. If the browser either doesn't redirect, or switches the method to GET, then it fails.

Test case:
Browser sends a POST to /test1/, Server responds 307, Location: /test2/
Browser must POST to /test2/. (if it either doesn't redirect, or uses GET on the 2nd request, it fails).

I don't really care much about the difference between 307 and 308. Like you hinted above, it's mostly for search engines, though I assume the browser will cache 308 as hard as they cache a 301. I personally only need to use the 307 code currently, and I don't really care if the browser is caching 308's or not.

(I also think this issue should be renamed something like 307/308 resume/redirect keep verb)

+1
I'm curious what the browser support is for the new 307 and 308 status codes. If the browser correctly redirects to the new location while preserving the method (like POST), then the browser has the feature implemented correctly. If the browser either doesn't redirect, or switches the method to GET, then it fails.

Test case:
Browser sends a POST to /test1/, Server responds 307, Location: /test2/
Browser must POST to /test2/. (if it either doesn't redirect, or uses GET on the 2nd request, it fails).

I don't really care much about the difference between 307 and 308. Like you hinted above, it's mostly for search engines, though I assume the browser will cache 308 as hard as they cache a 301. I personally only need to use the 307 code currently, and I don't really care if the browser is caching 308's or not.

(I also think this issue should be renamed something like 307/308 resume/redirect keep verb)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 17, 2016

+1
Showing the support for 307 and 308 is helpful.

ghost commented Jul 17, 2016

+1
Showing the support for 307 and 308 is helpful.

@booch

This comment has been minimized.

Show comment
Hide comment
@booch

booch Jul 19, 2016

It'd be nice to show support for 308. (I suspect that 307 is well-supported, since it's a part of the 1999 HTTP/1.1 spec; 308 was added in 2014 via RFC 7238.)

I found a checker at http://webdbg.com/test/308/. A few data points of browsers that support 308, according to that test:

  • Microsoft Edge 25.1 (desktop)
  • Google Chrome 51 (desktop and mobile)
  • Firefox 47 (desktop and mobile)
  • Safari 9.1 (desktop and mobile)
  • Android browser 6.0

Which means that, contrary to all the info I found on the Internet, I can use a 308 response code, at least if I'm supporting only current browsers.

booch commented Jul 19, 2016

It'd be nice to show support for 308. (I suspect that 307 is well-supported, since it's a part of the 1999 HTTP/1.1 spec; 308 was added in 2014 via RFC 7238.)

I found a checker at http://webdbg.com/test/308/. A few data points of browsers that support 308, according to that test:

  • Microsoft Edge 25.1 (desktop)
  • Google Chrome 51 (desktop and mobile)
  • Firefox 47 (desktop and mobile)
  • Safari 9.1 (desktop and mobile)
  • Android browser 6.0

Which means that, contrary to all the info I found on the Internet, I can use a 308 response code, at least if I'm supporting only current browsers.

@gagern

This comment has been minimized.

Show comment
Hide comment
@gagern

gagern Nov 18, 2016

The specs leave different options for clients, and caniuse could document which browsers use which of these. RFC 2616 writes

If the {301,302,307} status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

but that requirement appears to be gone from RFC 7231 or RFC 7538. These write that

The user agent MAY use the Location field value for automatic redirection.

and

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

for many of the requests. So we could examine features like whether the browser does redirect automatically without user intervention, or automatically after asking for confirmation, or not automatically at all. Based on all combinations of status code, request method, perhaps whether the new location is on the same or a different domain, and perhaps which of the locations use HTTPS. Not sure which of these might make a difference. And I'd also like to see which browsers actually turn POST into GET here. Quite a lot of browser-specific behavior here.

gagern commented Nov 18, 2016

The specs leave different options for clients, and caniuse could document which browsers use which of these. RFC 2616 writes

If the {301,302,307} status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

but that requirement appears to be gone from RFC 7231 or RFC 7538. These write that

The user agent MAY use the Location field value for automatic redirection.

and

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

for many of the requests. So we could examine features like whether the browser does redirect automatically without user intervention, or automatically after asking for confirmation, or not automatically at all. Based on all combinations of status code, request method, perhaps whether the new location is on the same or a different domain, and perhaps which of the locations use HTTPS. Not sure which of these might make a difference. And I'd also like to see which browsers actually turn POST into GET here. Quite a lot of browser-specific behavior here.

@dwright

This comment has been minimized.

Show comment
Hide comment
@dwright

dwright May 30, 2017

+1 Would like to know if I can safely issue 307 or 308 redirects and expect modern browsers to know what to do with them. I'm not even concerned about what the browser does. Just knowing that it will try to do something with it instead of showing the user some kind of error would be beneficial.

dwright commented May 30, 2017

+1 Would like to know if I can safely issue 307 or 308 redirects and expect modern browsers to know what to do with them. I'm not even concerned about what the browser does. Just knowing that it will try to do something with it instead of showing the user some kind of error would be beneficial.

@Calico90

This comment has been minimized.

Show comment
Hide comment
@Calico90

Calico90 Jun 2, 2017

Contributor

+1

Contributor

Calico90 commented Jun 2, 2017

+1

@AlexPiksel

This comment has been minimized.

Show comment
Hide comment
@AlexPiksel

AlexPiksel Nov 9, 2017

+1 for 307/308 support.

+1 for 307/308 support.

@mattkemp

This comment has been minimized.

Show comment
Hide comment

mattkemp commented Jan 3, 2018

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment