André Warnier wrote: > > The area of contention here is whether a HTTP PUT request can or not > have "parameters", and whether such parameters can or not be encoded as > part of the HTTP body of a PUT request (or as part of the URL query > string of the request).
As far as I can tell, this is a Tomcat issue, not an HTTP one. Technically, HTTP requests do not have "parameters", regardless of the HTTP method (GET, POST, etc). HTTP requests have a Request-URI, which can have a query-string part; headers; and in some cases a content-body (aka "entity"). The server and anything it delegates the request to can make use of any of those in determining how to handle the request. But RFC 2616 does not define request "parameters". That is an informal concept, as far as HTTP is concerned. Since the HTTP/1.1 specification (RFC 2616) lets a PUT request include a query-string as part of its Request-URI (see below), if a query-string can be treated as "parameters", then a PUT request can have parameters. The same argument applies to the request headers and content-body of a PUT request. (Note that request headers are commonly used to convey metadata about the content-body to server-side application code; but they're not restricted to that purpose.) > Basically (and roughly), > - for a GET (which does not have a body), such request parameters are > encoded as part of the request URL "query string" part True, though it would be more accurate to say that since a GET request cannot include a content-body, its only channels for notional "parameters" are the query-string and the request headers. > - for a POST request (which has a body), the parameters are encoded the > same way, but are contained in the HTTP body of the request. Any HTTP request method other than CONNECT, including a POST request, can include a query-string in its Request-URI. See 2616 3.2, 5.1.2, and 9. Also, the other parts of the Request-URI can be treated as application parameters. See for example the definition of "path-info" in the CGI/1.1 specification: the CGI program is identified by the part of the abs_path that includes the actual name of an executable (as defined by the server), but the abs_path can contain additional components after that which are made available to the program (possibly after transformation by the server) via the environment. And the "parameters" in the content-body of a POST request do not need to be URL-encoded. Some HTTP applications, such as HTML, do define POST entities that are URL-encoded - notably HTML's use of URL-encoding for form name/value pairs. But the POST request content-body can be any stream of octets, and its interpretation is left to whatever processes the request. > For PUT requests however, there is no mention anywhere (in the > applicable specs) of parameters. 2616 9.6 says that a PUT request includes a Request-URI. 5.1.2 says that will be an absoluteURI or an abs_path. (A PUT request must refer to a resource, so "*" is not allowed; and the fourth option, an authority, is only allowed for the CONNECT request method.) And 3.2.2 includes the query string as part of an http_URL. (RFC 2616 *is* somewhat sloppy in this regard, because 3.2.2 incorrectly separates abs_path and query, which suggests that eg a GET request cannot be made using an abs_path with a query string - ie, that it would have to be made using an absoluteURI in order to a query string. There are various proposed fixes for this; see eg i58 in the HTTP rfc2616bis issues list at [1].) > In fact, the HTTP RFC definition of a PUT request seems to indicate that > the body contains the "resource" that the client wants the server to > store at the location corresponding to the indicated request URL. Correct. The intention of the PUT request is to ask the origin server to store an entity; the content-body contains the entity, and the Request-URI names it. > For all these reasons, currently Tomcat does not support the > getParameters() family of methods, when the request method is PUT. This is a Tomcat limitation, not an HTTP one. It's not a conformance issue, because RFC 2616 doesn't require the server do anything in particular with the query-string. But it does permit a query-string in a PUT Request-URI. > It is possible that other servlet engines support this, but in that case > it has to be considered as an optional add-on, not as something that is > required by the HTTP RFC nor the Servlet Spec. Agreed. > But the crux of the matter is, that if a (REST) web application would > depend on that feature to be available in an HTTP server or a Servlet > Engine, then that application is not portable, because the applicable > specifications do not mention this as a mandatory feature of either of > them. Agreed. Of course, even if you limit yourself to conforming HTTP servers, it can be difficult to be completely portable; HTTP/1.1 doesn't have all that many requirements. A conforming HTTP/1.1 server only has to support GET and HEAD, for example (5.1.1). [1] http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
