You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by bu...@apache.org on 2003/04/14 16:48:11 UTC

DO NOT REPLY [Bug 18996] New: - Ordering of methods in PostMethod changes behaviour

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18996>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18996

Ordering of methods in PostMethod changes behaviour

           Summary: Ordering of methods in PostMethod changes behaviour
           Product: Commons
           Version: 1.0 Alpha
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: HttpClient
        AssignedTo: commons-httpclient-dev@jakarta.apache.org
        ReportedBy: ajmas@bigfoot.com


I have just spent the best part of two days trying to work out why
a servlet running in Tomcat was not getting UTF-8 when I had set my
client to send UTF-8. It turns out that if I set my PostMethod request
header after setting the request body the content does not get sent as
UTF-8.

The following gets sent as UTF-8:

      PostMethod post = new PostMethod(destinationUrl.toString());
      post.setStrictMode(false);
      post.setRequestHeader("Content-Type","text/xml; charset=UTF-8");
      post.setRequestHeader("user-agent", "myAgent");
      post.setRequestBody(content);
      post.setFollowRedirects(true);

the following doesn't:

      PostMethod post = new PostMethod(destinationUrl.toString());
      post.setStrictMode(false);
      post.setRequestBody(content);
      post.setRequestHeader("Content-Type","text/xml; charset=UTF-8");
      post.setRequestHeader("user-agent", "myAgent");
      post.setFollowRedirects(true);

In a live execution I would understand that order makes a big difference, but
when you fill out an object that feels like defining the values of a Java Bean
this likely to be less obvious.