On 03/12/2010 16:07, schu...@apache.org wrote:
> Author: schultz
> Date: Fri Dec 3 16:07:50 2010
> New Revision: 1041892
>
> URL: http://svn.apache.org/viewvc?rev=1041892&view=rev
> Log:
> Fixed bug 48692: Provide option to parse application/x-www-form-urlencoded
> PUT requests
Some minor comments in-line.
> + protected HashSet parseBodyMethodsSet;
This needs to use generics (same for subsequent use later on in the class).
> + public String getParseBodyMethods()
> + {
> + return (this.parseBodyMethods);
> + }
The Tomcat code style is to have brackets at the end of the previous line.
> + if(methodSet.contains("TRACE"))
> + throw new IllegalArgumentException("TRACE method MUST NOT
> include an entity (see RFC 2616 Section 9.6)");
This should use the StringManager for i18n support.
> + public boolean isParseBodyMethod(String method)
This method could (should?) be protected rather then public.
> - if (!getMethod().equalsIgnoreCase("POST"))
> + if(!getConnector().isParseBodyMethod(getMethod()))
The Tomcat code style is to have a space after the if.
> <changelog>
> + <update>
> + <bug>48692</bug>: Provide option to parse
> + <code>application/x-www-form-urlencoded</code> PUT requests.
> (schultz)
> + </update>
> <fix>
> <bug>8705</bug>: <code>org.apache.catalina.SessionListener</code> now
> extends <code>java.util.EventListener</code>. (markt)
Bugs get added to the changelog in ascending numerical order within the
appropriate section.
> + <attribute name="parseBodyMethods" required="false">
> + <p>A comma-separated list of HTTP methods for which request
> + bodies will be parsed for request parameters identically
> + to POST. This is useful in RESTful applications that want to
> + support POST-style semantics for PUT requests.
> + Note that any setting other than <code>POST</code> causes Tomcat
> + to behave in a way that violates the servlet specification.
> + The HTTP method TRACE is specifically forbidden here in accordance
> + with the HTTP specification.
> + The default is <code>POST</code></p>
> + </attribute>
"violates" is probably too strong a term here. There is some wiggle
room in the language. I would suggest "goes against the intent" is
probably closer.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
