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.


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


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to