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

11–20 of 75 posts

Re: HTTP/1.1 just got a major update

#11

Post by treve »

derengel wrote: post #9

As someone new to HTTP, what would be the most pragmatic way to read through this RFCs in the context of building web applications or HTTP APIs but not to the level of wanting to implement a http server or http client? for example: order of reading, what can be avoided, what is not widely use or implemented, the basics of the protocol, etc...

On a high level:

You can certainly skip most of "Message Syntax and Routing". That's the stuff that concerns server and client implementers that just have tcp sockets to work with.

I would absolutely read "Semantics and Content". It's a really good idea to be aware of "Conditional Requests", and you only really have to read "Caching", "Range requests" and "Authentication" if you need to know about those features.

Re: HTTP/1.1 just got a major update

#12

Post by argonaut »

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 there something wrong with violating a REST principle?

Re: HTTP/1.1 just got a major update

#13

Post by userbinator »

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 concise and to-the-point. Some of the sentences in the new RFCs seem almost parenthetical (e.g. look at the description of GET.)

Re: HTTP/1.1 just got a major update

#14

Post by treve »

wtetzner wrote: post #10
colanderman wrote: post #8

Earlier quoted context omitted.

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

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.

Re: HTTP/1.1 just got a major update

#15

Post by muaddirac »

derengel wrote: post #9

As someone new to HTTP, what would be the most pragmatic way to read through this RFCs in the context of building web applications or HTTP APIs but not to the level of wanting to implement a http server or http client? for example: order of reading, what can be avoided, what is not widely use or implemented, the basics of the protocol, etc...

HTTP methods, status codes, and headers are all you need to understand for developing at the level of HTTP APIs.

Re: HTTP/1.1 just got a major update

#16

Post by saryant »

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?

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.

Re: HTTP/1.1 just got a major update

#17

Post by xxs »

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.

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

Re: HTTP/1.1 just got a major update

#18

Post by icebraining »

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 is if you don't want to lose advantages that following them bring. That said, I don't see how this would break any REST principles.

Re: HTTP/1.1 just got a major update

#19

Post by jalfresi »

muaddirac wrote: post #15
derengel wrote: post #9

As someone new to HTTP, what would be the most pragmatic way to read through this RFCs in the context of building web applications or HTTP APIs but not to the level of wanting to implement a http server or http client? for example: order of reading, what can be avoided, what is not widely use or implemented, the basics of the protocol, etc...

HTTP methods, status codes, and headers are all you need to understand for developing at the level of HTTP APIs.

And media-types and rel types if you're developing HTTP APIs

Re: HTTP/1.1 just got a major update

#20

Post by masklinn »

muaddirac wrote: post #15
derengel wrote: post #9

As someone new to HTTP, what would be the most pragmatic way to read through this RFCs in the context of building web applications or HTTP APIs but not to the level of wanting to implement a http server or http client? for example: order of reading, what can be avoided, what is not widely use or implemented, the basics of the protocol, etc...

HTTP methods, status codes, and headers are all you need to understand for developing at the level of HTTP APIs.

The problem being that it's been spread all over the specs.

The essentials would be:

* 7231 which covers core methods, statuses and basic headers. It looks like the spec authors have also added security considerations sections

* 7232 is probably a good read as it covers conditional requests (304 and 412 statuses)

* 7234 covers caching and cache controls, don't skip it. Even if you don't want your response to be cached, you need to know how caching works, which actors are involved and how to disable it

* 7238 is the 308 redirection, understanding it and the background for its introduction is a good idea and will help with understanding other redirection statuses (301, 302 and 307)

"Various others" would be

* 7233 is Range requests, can probably be skipped unless you have big media payloads. On one hand it's underused, on the other hand it has limited general applicability

* 7235 is Authentication, can be useful for API (the user experience being terrible for browsers) but can probably be skipped unless absolutely necessary

* 7239 is forwarding, to understand what happens when your HTTP endpoint is behind a proxy. Although I'd guess proxies don't implement it yet the ideas already existed as non-standard extensions and reading this is a good idea for "real-world" concerns. Not completely necessary, but useful

* 7240 is the Prefer header. It's a fairly recent and quite advanced addition, probably useful but not utterly necessary

You can ignore

* 7230 is about req/resp format. The only interesting parts are the URI and Host parts which your HTTP library probably handles for you

* 7236 complements 7235 with auth scheme registration for standard auth types. Only read it if you've read 7235

* 7237 is a registry of additional (wrt 7231) methods, mostly from WebDAV

Post reply on HN