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

71–75 of 75 posts

Re: HTTP/1.1 just got a major update

#71

Post by cbr »

sergiosgc wrote: post #51
gorhill wrote: post #50

Earlier quoted context omitted.

> This then allows sites to distinguish between direct traffic from users that don't block referrers and traffic with blocked referrers Any example of benefits for servers to distinguish direct traffic vs. blocked referrers?

When analyzing traffic sources for your site, you could use this to remove noise created by privacy conscious users. For example, if you wish to evaluate the efficiency of a magazine add, today you can't distinguish between ad conversions and privacy conscious users. It'll take a while for clients to be compliant, if they'll ever be, though.

Use a custom landing page url in the magazine ad that's not linked online.

Re: HTTP/1.1 just got a major update

#72

Post by perbu »

profil wrote: post #35
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.

Are you lacking OSS HTTP/1.1 servers to study? There are tons.

Re: HTTP/1.1 just got a major update

#73

Post by itsadok »

gsnedders wrote: post #62
zurn wrote: post #40

Earlier quoted context omitted.

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

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

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/2086

Re: HTTP/1.1 just got a major update

#74

Post by ajanuary »

dragonwriter wrote: post #68
gioele wrote: post #27

Earlier quoted context omitted.

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

> Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response. Well, except that since the body isn't defined as having semantics that determine the response, an cache based on the HTTP protocol spec has no reason to do that.

Talking from a practical standpoint, to try and have GET requests with large parameters you could put the data in the message body, and then a hash of the message in the URL to avoid caching issues.

Re: HTTP/1.1 just got a major update

#75

Post by lttlrck »

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?

Is it really so different to URI encoded parameters?
Post reply on HN