3 ms·
There are two valid reasons I can think of why the verbs need to be specified somewhere for universal agreement: - So that proxies can potentially retry idempo
by stormbrew 13y ago
There are two valid reasons I can think of why the verbs need to be specified somewhere for universal agreement:
- So that proxies can potentially retry idempotent requests if the upstream fails. Retrying a partially sent GET should be ok, while retrying a partially sent POST is a terrible idea. It's nice in theory, but in practice only reverse proxies at the application endpoint really have the information necessary to make this decision, since many sites have non-idempotent GETs.
- Because it affects whether or not there's a request or response body. GETs have no request body but should have a response body. POST/PUT/etc. should have both a request and response body. HEADs have neither a request nor response body. At the moment the only way for an intermediary to know whether a request is finished is because it understands these methods, and this is also true of any extension methods (which is why proxies should generally fail on unknown methods).
Mostly it comes down to an issue of routing. And in the end, the ability to have working proxies was an important factor in the popularity of the web imo.
But really the first issue is largely moot already and the latter could be fixed in the protocol so that presence or absence of a body could be signalled in the protocol itself (probably is in http2.0 actually).
All of that aside, though, http2.0 may never fully replace http1.1. I think there may even be a large portion of the web development community that is hoping it won't. In which case, interop will keep those verbs in place forever.
- Eiwatah4 13y ago> At the moment the only way for an intermediary to know whether a request is finished is because it understands these methods, and this is also true of any extension methods I read the HTTP 1.1 RFC differently. Requests must indicate a body with a Content-Length or Transfer-Encoding header. Responses always have a body (sometimes of length 0), unless it is a response to a HEAD request or has one of a very small number of response codes. http://tools.ietf.org/html/rfc2616#section-4.3 http://tools.ietf.org/html/rfc2616#section-4.3
- meddlepal 13y agoAs I understand it... Only convention is the reason GET does not usually a body. The spec doesn't prevent it.