Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/1.1 just got a major update

evertpot.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: HTTP/1.1 just got a major update

#31

Post by robryk »

saryant wrote: post #16
colanderman wrote: post #8

Earlier quoted context omitted.

Pardon my ignorance but how are GET payloads useful? Does that not violate REST principles?

Elasticsearch: it accepts JSON bodies in GET requests to define the parameters of a search. These can get quite large so it's preferable to encoding everything in the query string. The operation is read-only, so an argument can be made that a GET makes more sense than a POST. That said, I POST my search params to Elasticsearch anyways.

Aren't message bodies on GET supposed not to impact the returned result at all?

Re: HTTP/1.1 just got a major update

#32

Post by nileshtrivedi »

masklinn wrote: post #21
treve wrote: post #14

Earlier quoted context omitted.

It's still a bad idea. It has no defined semantics, meaning that servers, clients, proxies and anything else are free to ignore or drop it. It also defeats caching and any other reasons why you would want to use GET over some other http requests. I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing.

> I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing. Not all systems support practically unlimited URI payloads[0]. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST. For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This i…

Another example: Searching for images similar to a specified one.

Re: HTTP/1.1 just got a major update

#33

Post by thegregjones »

gioele wrote: post #27
treve wrote: post #14

Earlier quoted context omitted.

It's still a bad idea. It has no defined semantics, meaning that servers, clients, proxies and anything else are free to ignore or drop it. It also defeats caching and any other reasons why you would want to use GET over some other http requests. I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing.

> It also defeats caching and any other reasons why you would want to use GET over some other http requests. It does not break caching. Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response.

Do any caches operate like that?

Re: HTTP/1.1 just got a major update

#34

Post by 0x0 »

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?

Re: HTTP/1.1 just got a major update

#35

Post by profil »

gamegoblin wrote: post #3

And I just finished implementing 2616 in a toy server of mine. Sigh. C'est la vie. I'm glad this new spec apparently resolves a lot of ambiguities. I hated reading 2616 and some specs it depended on (email, URI, etc).

Is your toy server open source? I would love to see the source.

Re: HTTP/1.1 just got a major update

#36

Post by masklinn »

nileshtrivedi wrote: post #32
masklinn wrote: post #21

Earlier quoted context omitted.

> I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing. Not all systems support practically unlimited URI payloads[0]. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST. For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This i…

Another example: Searching for images similar to a specified one.

A great example, image search already being fairly common (and being useful to all sorts of purposes)

Re: HTTP/1.1 just got a major update

#37

Post by Lukasa »

0x0 wrote: post #34

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?

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.

Re: HTTP/1.1 just got a major update

#38

Post by masklinn »

0x0 wrote: post #34

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?

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).

Re: HTTP/1.1 just got a major update

#39

Post by mjs »

The thing I'm most surprised by is the change in the default cacheability of 404 responses from uncacheable to cacheable. Though I guess since defaulting to cacheable doesn't mean that responses must be cached, so you can still be compliant with RFC7231 by never caching 404s.

RFC2616:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...

"A response received with [a status code other than 200, 203, 206, 300, 301 or 410] MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it."

RFC7231:

http://tools.ietf.org/html/rfc7231#section-6.5.4

"A 404 response is cacheable by default"

Re: HTTP/1.1 just got a major update

#40

Post by zurn »

masklinn wrote: post #38
0x0 wrote: post #34

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?

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).

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

Post reply on HN