HTTP/1.1 just got a major update • Hacker News Board

Re: HTTP/1.1 just got a major update

#51

Post by sergiosgc » Sat, Jun 07, 2014, 12:53 PM UTC

gorhill wrote: post #50

robryk wrote: post #30

Earlier quoted context omitted.

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?

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.

Re: HTTP/1.1 just got a major update

#52

Post by gorhill » Sat, Jun 07, 2014, 1:03 PM UTC

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.

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

Re: HTTP/1.1 just got a major update

#53

Post by TheLoneWolfling » Sat, Jun 07, 2014, 1:11 PM UTC

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…

Yep.

Yet another way to fingerprint.

Re: HTTP/1.1 just got a major update

#54

Post by acdha » Sat, Jun 07, 2014, 1:24 PM UTC

Joeri wrote: post #46

saryant wrote: post #16

Earlier quoted context omitted.

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.

GET vs. POST is a question of whether the request is intended to change state. Using JSON for a query is nice for preserving structure (e.g. nesting a Boolean expressions, not needing PHP-style array notation, etc.) but it doesn't change the idea that it's a GET request which can safely be repeated without affecting server state, may be cached for other clients, etc.

Re: HTTP/1.1 just got a major update

#55

Post by mrottenkolber » Sat, Jun 07, 2014, 1:34 PM UTC

I am still happily speaking HTTP/1.0 [1] :)

[1] http://mr.gy/software/httpd0/

Re: HTTP/1.1 just got a major update

#56

Post by colanderman » Sat, Jun 07, 2014, 1:47 PM UTC

charonn0 wrote: post #49

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.

> 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

Re: HTTP/1.1 just got a major update

#57

Post by colanderman » Sat, Jun 07, 2014, 1:51 PM UTC

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…

Copy+paste them into one text file?

Re: HTTP/1.1 just got a major update

#58

Post by colanderman » Sat, Jun 07, 2014, 1:54 PM UTC

robryk wrote: post #31

saryant wrote: post #16

Earlier quoted context omitted.

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?

Yes: http://stackoverflow.com/a/983458

Re: HTTP/1.1 just got a major update

#59

Post by [deleted] » Sat, Jun 07, 2014, 1:56 PM UTC

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

[deleted]

Re: HTTP/1.1 just got a major update

#60

Post by colanderman » Sat, Jun 07, 2014, 2:00 PM UTC

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?

From the horse's mouth; they are not useful: https://groups.yahoo.com/neo/groups/rest-discuss/conversatio...