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

41–50 of 75 posts

Re: HTTP/1.1 just got a major update

#41

Post by RobAley »

thegregjones wrote: post #33
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.

Do any caches operate like that?

Not many I would think. For compatibility with existing caches, you could do something like add an extra parameter to the URL with a hash of the message body. In the case of e.g. an image or music file given elsewhere in this thread, the cache doesn't actually need the full contents of the image file (like the backend does), just something like a hash to match it to a previous request.

Re: HTTP/1.1 just got a major update

#43

Post by 0x0 »

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

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

Re: HTTP/1.1 just got a major update

#44

Post by 0x0 »

Lukasa wrote: post #37
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.

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?

Re: HTTP/1.1 just got a major update

#45

Post by shawnz »

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

Earlier quoted context omitted.

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

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

Try it out: http://webdbg.com/test/308/

I get failures in Chrome and IE. Firefox passes if I click OK in a funny dialog.

Re: HTTP/1.1 just got a major update

#46

Post by Joeri »

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.

Is that really restful though? If you need that many parameters to specify which resource you mean, you lose pretty much all of the benefit of a restful architecture.

Re: HTTP/1.1 just got a major update

#47

Post by 0x0 »

shawnz wrote: post #45
0x0 wrote: post #43

Earlier quoted context omitted.

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

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

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.

Re: HTTP/1.1 just got a major update

#48

Post by Vieira »

shawnz wrote: post #45
0x0 wrote: post #43

Earlier quoted context omitted.

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

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

It is working in Chrome Beta for Android (v36)

Re: HTTP/1.1 just got a major update

#49

Post by charonn0 »

shawnz wrote: post #45
0x0 wrote: post #43

Earlier quoted context omitted.

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

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

> 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

[2]: http://tools.ietf.org/html/rfc2616#section-9.1.2

[3]: http://tools.ietf.org/html/rfc2616#section-10.3.2

Edit: links

Re: HTTP/1.1 just got a major update

#50

Post by gorhill »

robryk wrote: post #30
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.

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

Post reply on HN