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

61–70 of 75 posts

Re: HTTP/1.1 just got a major update

#61

Post by cheald »

gorhill wrote: post #52
sergiosgc wrote: post #51

Earlier quoted context omitted.

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.

> if you wish to evaluate the efficiency of a magazine ad Sorry I still don't get it. No referrer or about:blank are both "noise" in such case, I still don't see how the distinction is useful to the server to evaluate efficiency of a particular ad.

"about:blank" usually means "was opened from an external program, such as an IM client".

"No referrer" means "A referrer may have existed, but inclusion of that information was explicitly declined as a part of the request".

Both are useful.

Re: HTTP/1.1 just got a major update

#62

Post by gsnedders »

zurn wrote: post #40
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).

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

Re: HTTP/1.1 just got a major update

#63

Post by charonn0 »

colanderman wrote: post #56
charonn0 wrote: post #49

Earlier quoted context omitted.

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

No, idempotency doesn't matter because the action is not applied when a 3xx is returned. Proof: permanent 3xx replies are cacheable. The reason confirmation is asked is because the user might not wish to apply the action to the new URI. (Codified as "safety" in the new 1.1.) Sources: your links and http://tools.ietf.org/html/rfc7231#section-4.2.1

Responses to POST requests are only cacheable when they include explicit freshness information[1], which is not the case with the linked test page.

[1]: http://tools.ietf.org/html/rfc7231#section-4.3.3

Re: HTTP/1.1 just got a major update

#64

Post by FooBarWidget »

grk wrote: post #42
__david__ wrote: post #7

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

Phusion passenger throws 500 on get requests with body, I guess now they might change that.

Actually we've already changed that. It's slated for 4.0.45, due next week.

Re: HTTP/1.1 just got a major update

#65

Post by kccqzy »

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…

The standard doesn't seem to suggest that. Quote from http://tools.ietf.org/html/rfc7231#section-5.5.2

    If the target URI was obtained from a source that does not have its
    own URI (e.g., input from the user keyboard, or an entry within the
    user's bookmarks/favorites), the user agent MUST either exclude the
    Referer field or send it with a value of "about:blank".
Am I missing anything?

Re: HTTP/1.1 just got a major update

#66

Post by dragonwriter »

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?

They aren't. HTTP has a layered design, and the structure of requests is a lower level feature than the semantics of specific request type -- a request can always have a body, but that doesn't mean that there aren't request types (e.g., GET) for which the body is meaningless.

> Does that not violate REST principles?

Most attempts to impose semantics on GET bodies would violate REST principles as well as breaking HTTP (given that GET responses are cacheable and the body is treated as not relevant to the response.)

Re: HTTP/1.1 just got a major update

#67

Post by dragonwriter »

argonaut wrote: post #12
colanderman wrote: post #8

Earlier quoted context omitted.

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

Is there something wrong with violating a REST principle?

There's something wrong with breaking the semantics of GET; all the revision does is clarify that the syntax of HTTP is method-independent so that message bodies aren't syntax errors, but GET bodies still have no semantic meaning and ascribing one to them is likely to mean you server is doing things that clients, caches, etc., won't correctly handle.

Re: HTTP/1.1 just got a major update

#68

Post by dragonwriter »

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.

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

Re: HTTP/1.1 just got a major update

#69

Post by dragonwriter »

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?

Per the applicable RFC (7238):

   Section 6 of [RFC7231] requires recipients to treat unknown 3xx
   status codes the same way as status code 300 Multiple Choices
   ([RFC7231], Section 6.4.1).  Thus, servers will not be able to rely
   on automatic redirection happening similar to status codes 301, 302,
   or 307.

   Therefore, initial use of status code 308 will be restricted to cases
   where the server has sufficient confidence in the client's
   understanding the new code or when a fallback to the semantics of
   status code 300 is not problematic.

Re: HTTP/1.1 just got a major update

#70

Post by dragonwriter »

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

Earlier quoted context omitted.

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.

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.)
Post reply on HN