4 ms·

Why is it not called HTTP/1.2? Or, how will clients (or servers) tell the difference between a peer implementing RFC 2616 (HTTP/1.1 old version) and RFC 723x (H

by 0x0 12y ago

Why is it not called HTTP/1.2? Or, how will clients (or servers) tell the difference between a peer implementing RFC 2616 (HTTP/1.1 old version) and RFC 723x (HTTP/1.1 new version)? Could it be that there is so much software hardcoded to look for "HTTP/1.1" that a "HTTP/1.2" string would break them all?

Lukasa 12y ago
The argument is that the two should be able to transparently interop together, and specifically that RFC 723[0-5] simply codifies the way HTTP/1.1 already works in the real world. We'll see how well that goes.
- 0x0 12y ago
  Shouldn't minor revisions of HTTP interop anyways? I.e. a HTTP/1.2 server should be able to talk with a HTTP/1.1 client even if they use different minor versions in their protocol string? So, it "SHOULDN'T" hurt to bump the version to 1.2, plus it would make it easier to identify up to date spec compliance?
masklinn 12y ago
Because it does not really change the protocol. It clarifies details and implements spec fixes (e.g. matches the spec better to actual real-world use).
- zurn 12y ago
  There are significant changes of semantics according to TFA, for example: > Default charset of ISO-8859-1 has been removed > The 204, 404, 405, 414 and 501 status codes are now cachable. > The Location header can now contain relative uri's as well as fragment identifiers
  - gsnedders 12y ago
    All three are things pretty much all HTTP/1.1 clients have done for over a decade. It's incompatible with RFC2616, yes — but not with implementations of "HTTP/1.1".
    - itsadok 12y ago
      Python's requests library maintainers insisted on sticking with this annoying and surprising rule (default charset of ISO-8859-1), because that's what the RFC says they should do. Hopefully, they'll reconsider now. https://github.com/kennethreitz/requests/issues/1737 https://github.com/kennethreitz/requests/issues/1737 https://github.com/kennethreitz/requests/issues/2086 https://github.com/kennethreitz/requests/issues/2086
- 0x0 12y ago
  Can you send a 308 permanent redirect to existing software and get the expected behavior?
  - 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

by 0x0 12y ago

Lukasa 12y ago

The argument is that the two should be able to transparently interop together, and specifically that RFC 723[0-5] simply codifies the way HTTP/1.1 already works in the real world. We'll see how well that goes.

0x0 12y ago
Shouldn't minor revisions of HTTP interop anyways? I.e. a HTTP/1.2 server should be able to talk with a HTTP/1.1 client even if they use different minor versions in their protocol string? So, it "SHOULDN'T" hurt to bump the version to 1.2, plus it would make it easier to identify up to date spec compliance?

masklinn 12y ago

Because it does not really change the protocol. It clarifies details and implements spec fixes (e.g. matches the spec better to actual real-world use).

zurn 12y ago
There are significant changes of semantics according to TFA, for example: > Default charset of ISO-8859-1 has been removed > The 204, 404, 405, 414 and 501 status codes are now cachable. > The Location header can now contain relative uri's as well as fragment identifiers
- gsnedders 12y ago
  All three are things pretty much all HTTP/1.1 clients have done for over a decade. It's incompatible with RFC2616, yes — but not with implementations of "HTTP/1.1".
  - itsadok 12y ago
    Python's requests library maintainers insisted on sticking with this annoying and surprising rule (default charset of ISO-8859-1), because that's what the RFC says they should do. Hopefully, they'll reconsider now. https://github.com/kennethreitz/requests/issues/1737 https://github.com/kennethreitz/requests/issues/1737 https://github.com/kennethreitz/requests/issues/2086 https://github.com/kennethreitz/requests/issues/2086
0x0 12y ago
Can you send a 308 permanent redirect to existing software and get the expected behavior?
- 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