7157360: HttpURLConnection: HTTP method DELETE doesn't support output

[Chris Hegarty]

Hi Andreas,

Your changes look fine to me. Strange to include a body in a DELETE 
request, but seems harmless.

I noticed that the javafx issue is no longer dependent on this, but 
still worth fixing.

I can sponsor this change into jdk8 for you.

-Chris.

On 20/06/2013 23:04, Andreas Rieber wrote:
> Hi,
>
> here the next issue i would need a sponsor for. Also a very small one.
>
> Bug:
> http://bugs.sun.com/view_bug.do?bug_id=7157360
>
> Looked straight forward to me for the DELETE method, but from last
> issue i still have the HTTP/1.1 spec open. Here the relevant parts:
>
>  >>
> 4.3 Message Body
> ...
> The presence of a message-body in a request is signaled by the
> inclusion of a Content-Length or Transfer-Encoding header field in the
> request's message-headers. A message-body MUST NOT be included in a
> request if the specification of the request method (section 5.1.1)
> does not allow sending an entity-body in requests. A server SHOULD
> read and forward a message-body on any request; if the request method
> does not include defined semantics for an entity-body, then the
> message-body SHOULD be ignored when handling the request.
> ...
>
> 9.8 TRACE
> ...
> The TRACE method is used to invoke a remote, application-layer loop-
> back of the request message. The final recipient of the request
> SHOULD reflect the message received back to the client as the
> entity-body of a 200 (OK) response. The final recipient is either the
> origin server or the first proxy or gateway to receive a Max-Forwards
> value of zero (0) in the request (see section 14.31). A TRACE request
> MUST NOT include an entity.
> ...
>  >>
>
> To me 4.3 says: a server has to handle a request body (entity), no
> matter what request method is requested.
> 9.8 TRACE is the only request method where it says "MUST NOT include
> an entity".
>
> So the change i made is: allow request entity excluding for method
> TRACE, where it MUST NOT include one. Does sound right? This time the
> test was easy to write.
>
> Webrev is here:
> http://cr.openjdk.java.net/~arieber/7157360/webrev.00/
>
> thanks
> Andreas