4 ms·

Can you send a 308 permanent redirect to existing software and get the expected behavior?

by 0x0 12y ago

shawnz 12y ago
Try it out: http://webdbg.com/test/308/ http://webdbg.com/test/308/ I get failures in Chrome and IE. Firefox passes if I click OK in a funny dialog.
- 0x0 12y ago
  Worked in iOS Safari but failed in iOS Chrome. So, this new "HTTP/1.1" feature broke my existing (old-)HTTP/1.1 chrome browser! If they had called it HTTP/1.2 they could send a non-308 redirect to HTTP/1.1 clients and 308 to HTTP/1.2. Instead, we now have servers and clients both speaking "HTTP/1.1" (whatever that is this week) not able to interoperate. Poor job.
  - dragonwriter 12y ago
    RFC 7238 with the 308 status code isn't part of HTTP/1.1 (even under the new revision, which is in RFCs 7230-7235), its an experimental extension that expressly notes that implementers must be aware that HTTP/1.1 clients not specifically written to that extension will fall back to the behavior for status code 300 when status code 308 is encountered, and that 308 should not be used where that behavior is not acceptable. (This is the standard mechanism for extensibility in response codes within the existing high-level groupings in HTTP/1.1.)
- Vieira 12y ago
  It is working in Chrome Beta for Android (v36)
- charonn0 12y ago
  > Firefox passes if I click OK in a funny dialog. 308 preserves the HTTP verb[1], and the form on that page uses POST. POST is not idempotent[2], which means using it more than once with the same parameters may not yield the same output. For example, POSTing this comment form twice would append to the resource twice; as opposed to GETing twice which just returns the resource unmodified both times. Firefox correctly (under the old RFC for a 301 redirect[3]) asks for confirmation before automatically repeating a request that is not guaranteed to be safe to repeat. Some implementations will instead convert the request into a GET, which is why 308 was needed in the first place. [1]: http://tools.ietf.org/html/rfc7238#section-3 http://tools.ietf.org/html/rfc7238#section-3 [2]: http://tools.ietf.org/html/rfc2616#section-9.1.2 http://tools.ietf.org/html/rfc2616#section-9.1.2 [3]: http://tools.ietf.org/html/rfc2616#section-10.3.2 http://tools.ietf.org/html/rfc2616#section-10.3.2 Edit: links
  - colanderman 12y ago
    No, idempotency doesn't matter because the action is not applied when a 3xx is returned. Proof: permanent 3xx replies are cacheable. The reason confirmation is asked is because the user might not wish to apply the action to the new URI. (Codified as "safety" in the new 1.1.) Sources: your links and http://tools.ietf.org/html/rfc7231#section-4.2.1 http://tools.ietf.org/html/rfc7231#section-4.2.1
    - deleted 12y ago
      [deleted]
    - charonn0 12y ago
      Responses to POST requests are only cacheable when they include explicit freshness information[1], which is not the case with the linked test page. [1]: http://tools.ietf.org/html/rfc7231#section-4.3.3 http://tools.ietf.org/html/rfc7231#section-4.3.3
dragonwriter 12y ago
Per the applicable RFC (7238): Section 6 of [RFC7231] requires recipients to treat unknown 3xx status codes the same way as status code 300 Multiple Choices ([RFC7231], Section 6.4.1). Thus, servers will not be able to rely on automatic redirection happening similar to status codes 301, 302, or 307. Therefore, initial use of status code 308 will be restricted to cases where the server has sufficient confidence in the client's understanding the new code or when a fallback to the semantics of status code 300 is not problematic.

Can you send a 308 permanent redirect to existing software and get the expected behavior?

by 0x0 12y ago

Can you send a 308 permanent redirect to existing software and get the expected behavior?

Try it out: http://webdbg.com/test/308/ http://webdbg.com/test/308/ I get failures in Chrome and IE. Firefox passes if I click OK in a funny dialog.

0x0 12y ago
Worked in iOS Safari but failed in iOS Chrome. So, this new "HTTP/1.1" feature broke my existing (old-)HTTP/1.1 chrome browser! If they had called it HTTP/1.2 they could send a non-308 redirect to HTTP/1.1 clients and 308 to HTTP/1.2. Instead, we now have servers and clients both speaking "HTTP/1.1" (whatever that is this week) not able to interoperate. Poor job.
- dragonwriter 12y ago
  RFC 7238 with the 308 status code isn't part of HTTP/1.1 (even under the new revision, which is in RFCs 7230-7235), its an experimental extension that expressly notes that implementers must be aware that HTTP/1.1 clients not specifically written to that extension will fall back to the behavior for status code 300 when status code 308 is encountered, and that 308 should not be used where that behavior is not acceptable. (This is the standard mechanism for extensibility in response codes within the existing high-level groupings in HTTP/1.1.)
Vieira 12y ago
It is working in Chrome Beta for Android (v36)
charonn0 12y ago
> Firefox passes if I click OK in a funny dialog. 308 preserves the HTTP verb[1], and the form on that page uses POST. POST is not idempotent[2], which means using it more than once with the same parameters may not yield the same output. For example, POSTing this comment form twice would append to the resource twice; as opposed to GETing twice which just returns the resource unmodified both times. Firefox correctly (under the old RFC for a 301 redirect[3]) asks for confirmation before automatically repeating a request that is not guaranteed to be safe to repeat. Some implementations will instead convert the request into a GET, which is why 308 was needed in the first place. [1]: http://tools.ietf.org/html/rfc7238#section-3 http://tools.ietf.org/html/rfc7238#section-3 [2]: http://tools.ietf.org/html/rfc2616#section-9.1.2 http://tools.ietf.org/html/rfc2616#section-9.1.2 [3]: http://tools.ietf.org/html/rfc2616#section-10.3.2 http://tools.ietf.org/html/rfc2616#section-10.3.2 Edit: links
- colanderman 12y ago
  No, idempotency doesn't matter because the action is not applied when a 3xx is returned. Proof: permanent 3xx replies are cacheable. The reason confirmation is asked is because the user might not wish to apply the action to the new URI. (Codified as "safety" in the new 1.1.) Sources: your links and http://tools.ietf.org/html/rfc7231#section-4.2.1 http://tools.ietf.org/html/rfc7231#section-4.2.1
  - deleted 12y ago
    [deleted]
  - charonn0 12y ago
    Responses to POST requests are only cacheable when they include explicit freshness information[1], which is not the case with the linked test page. [1]: http://tools.ietf.org/html/rfc7231#section-4.3.3 http://tools.ietf.org/html/rfc7231#section-4.3.3

dragonwriter 12y ago

Per the applicable RFC (7238): Section 6 of [RFC7231] requires recipients to treat unknown 3xx status codes the same way as status code 300 Multiple Choices ([RFC7231], Section 6.4.1). Thus, servers will not be able to rely on automatic redirection happening similar to status codes 301, 302, or 307. Therefore, initial use of status code 308 will be restricted to cases where the server has sufficient confidence in the client's understanding the new code or when a fallback to the semantics of status code 300 is not problematic.