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

21–30 of 75 posts

Re: HTTP/1.1 just got a major update

#21

Post by masklinn »

treve wrote: post #14
wtetzner wrote: post #10

Earlier quoted context omitted.

I'm not sure how. As long as a GET request doesn't change your resources, it should be fine. The reason I can think of for sending a payload in a GET is if the data you wanted to send in a query string is too large.

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 is a purely readonly request, the backend just uses its information to identify the file and fetch whatever data and metadata on the file's content it has. But historically there was no choice but to route it via a semantically unsuitable POST.

[0] Apache defaults to 8190 bytes, IIS to 16384, Safari and Firefox support >100k but MSIE is limited to 2048

Re: HTTP/1.1 just got a major update

#22

Post by masklinn »

xxs wrote: post #17
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.

My thoughts exactly - GET with payload virtually means no caching.

If you've got to use body payloads, requests are probably way too big and unique for the involvement of caches browser or intermediate caches to be a good idea.

Re: HTTP/1.1 just got a major update

#23

Post by dsl »

BorisMelnik wrote: post #4

I wonder what Googlebot will make of this. There is a lot of debate already amongst search engine developers on which type of redirect to use.

Search engines largely handle all redirects the same, because they know nobody uses them correctly. If you aren't seeing the behavior you want, you can use Webmaster Tools or metadata to fix it.

Re: HTTP/1.1 just got a major update

#24

Post by masklinn »

userbinator wrote: post #13

I don't think splitting it up like that is such a good idea; now, instead of searching through one file, I have to remember that there are several and look through them all, just for one conceptual protocol. (TCP has a similar issue, although most of it is still in 793.) As for the extra verbosity, I'm not sure what to think; while some things may be specified more precisely, standards should also attempt to be conci…

OTOH, that means I don't have to dive through the minutiae of response message format when I'm just looking for the basic header stuff. All the important concerns (core, caching, conditional requests, auth and forwarding) get their own RFC and are thus easier to skim and search through. Although 308 and Range (and Prefer) also getting their RFCs is a bit weird. Likewise, syntax and routing get RFC 3270 so if you're implementing a client or server the reading experience should be much tighter,

Re: HTTP/1.1 just got a major update

#25

Post by lloeki »

The clarifications are very welcome but I wish it included embedded unit-less progress information on chunk encoding without having to rely on a side channel [0] (shameless plug, but any progress — ha ha — on this front would be fine)

[0]: https://github.com/lloeki/http-chunked-progress/blob/master/...

Re: HTTP/1.1 just got a major update

#26

Post by Cakez0r »

colanderman wrote: post #8
__david__ wrote: post #7

Finally, the spec is crystal clear that message bodies on GET requests are not illegal.

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

Having the parameters of your GET request in the query string or the request body doesn't have any semantic difference. You're just fetching a resource given some parameters, which doesn't violate REST principles.

Re: HTTP/1.1 just got a major update

#27

Post by gioele »

treve wrote: post #14
wtetzner wrote: post #10

Earlier quoted context omitted.

I'm not sure how. As long as a GET request doesn't change your resources, it should be fine. The reason I can think of for sending a payload in a GET is if the data you wanted to send in a query string is too large.

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.

Re: HTTP/1.1 just got a major update

#29

Post by cyphunk »

Great writeup. One issue...

   It's now suggested to use the about:blank uri in the
   Referer header when no referer exists, to distinguish
   between "there was no referrer" and "I don't want to 
   send a referrer".
For the sake of privacy would it not be better if there was no such distinction. Basically now any privacy conscious services need to add 'about:blank' as the referrer when users do not want to have their behaviour categorised and fingerprinted?

Re: HTTP/1.1 just got a major update

#30

Post by robryk »

cyphunk wrote: post #29

Great writeup. One issue... It's now suggested to use the about:blank uri in the Referer header when no referer exists, to distinguish between "there was no referrer" and "I don't want to send a referrer". For the sake of privacy would it not be better if there was no such distinction. Basically now any privacy conscious services need to add 'about:blank' as the referrer when users do not want to have their behaviour…

If a user doesn't want to send the referrer when there is no referrer, no referrer should be sent. This then allows sites to distinguish between direct traffic from users that don't block referrers and traffic with blocked referrers. I wouldn't expect this to be a significant concern, because the volume of actual direct traffic is not very large.
Post reply on HN