[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-971:
-----------------------------------------

       Priority: Minor  (was: Critical)
    Component/s: HttpMime

HttpClient sends Content-Type of the multipart form in the HTTP message head, 
which is consistent with the behaviour of all common browsers and multipart 
message parsers such as Commons FileUpload. 

I revisited the specification [1] [2] and have to admit it is not entirely 
clear whether the Content-Type header should be a part of the message head or 
the message body. The spec is simply ambiguous in that regard. However, given 
the common practice to put that header in the HTTP message head I think 
HttpClient's implementation is correct.

Unless someone can point out at a passage in the spec that clearly states 
otherwise, I am going to reject the bug as invalid. 

Oleg

[1] http://tools.ietf.org/html/rfc2388
[2] http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.2 

> Multipart Post / FileUpload is missing necessary boundary header
> ----------------------------------------------------------------
>
>                 Key: HTTPCLIENT-971
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-971
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpMime
>    Affects Versions: 4.0.1, 4.1 Alpha2
>         Environment: Ubuntu 10, Java 6
>         <dependency>
>             <groupId>org.apache.httpcomponents</groupId>
>             <artifactId>httpclient</artifactId>
>             <!--<version>4.0.1</version>-->
>             <version>4.1-alpha2</version>
>         </dependency>
>         <dependency>
>             <groupId>org.apache.httpcomponents</groupId>
>             <artifactId>httpmime</artifactId>
>             <!--<version>4.0.1</version>-->
>             <version>4.1-alpha2</version>
>         </dependency>
> 4.0.1 and 4.1-alpha2 have this bug. 
>            Reporter: Dominik Dorn
>            Priority: Minor
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> When doing a multipart post, with a code like this:
> <code>
>   HttpPost post = new HttpPost("http://"; + host + ":" + port + uploadUrl + 
> token.getProgressToken());
>     HttpContext context = new BasicHttpContext();
>     CookieStore store = cred.getCookieStore();
>     context.setAttribute(ClientContext.COOKIE_STORE, store);
>     MultipartEntity entity = new MultipartEntity();
>     HttpResponse response;
>     try{
>       entity.addPart("document[pdf_file]", new FileBody(file));
>       entity.addPart("authenticity_token", new 
> StringBody(token.getAuthenticityToken(), Charset.forName("UTF-8")));
>       entity.addPart("document[progress_token]", new 
> StringBody(token.getProgressToken(), Charset.forName("UTF-8")));
>       post.setEntity(entity);
>       HttpClient client = new DefaultHttpClient();
>       response = client.execute(post, context);
> </code>
> The required initializing Header
> <code>
> Content-Type: multipart/form-data; 
> boundary=---------------------------15590059519136285452113363602
> Content-Length: 38377
> -----------------------------15590059519136285452113363602
> Content-Disposition: form-data; name="authenticity_token"
> VkJ/mnCDmImYfEVT0zNFBvyyhihKSaUX5j7Vm7d0WUQ=
> </code>
> is missing. 
> Instead it directly starts with
> <code>
> --gDRYDFqyzjuUrRL5No6B5wHN6BT5Ts2
> Content-Disposition: form-data; name="authenticity_token"
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> rvMzKRruVZaKX7JV+4Zpg7LWdxEuhq2hSgtaCIcSzCg=
> </code>
> The target server ( a rails one ) seems not to be able to understand this 
> multipart upload. 
> I think the correct place to fix is 
> org.apache.http.entity.mime.MultipartEntity but I'm not sure where and how to 
> do it.
> Please help. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to