You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Kevin Tobin (JIRA)" <ji...@apache.org> on 2011/08/01 03:15:09 UTC
[jira] [Created] (HTTPCLIENT-1112) HttpClient JSF issue - missing
line feed character causes JSF file upload parse to fail.
HttpClient JSF issue - missing line feed character causes JSF file upload parse to fail.
----------------------------------------------------------------------------------------
Key: HTTPCLIENT-1112
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1112
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpMime
Affects Versions: 4.1.1
Environment: Any environment.
Reporter: Kevin Tobin
Fix For: 4.1.2
We have an application that cannot read the mime multipart generated by HttpClient's HttpMime library but
can read mime created by any other browser.
Turns out that the only difference between the HttpClient mime multipart data is a missing linefeed at the very end of the
the content body.
The HTTPMime Java code definitely writes out the last dash dash CR and LF i.e. "--\r\n" into its internal buffers... but the generated final output stream is one byte short.
>From a useability perspective this does not affect HTTP Client as it is able to read mime multipart missing the linefeed... but it does affect other non http lcienconsumers of the generated data,
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1112) HttpClient JSF issue - missing
line feed character causes JSF file upload parse to fail.
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1112.
-------------------------------------------
Resolution: Invalid
Fix Version/s: (was: 4.1.2)
I reviewed the source and found no evidence of HttpMime code miscalculating Content-Length value.
Feel free to re-open the issue if you can reproduce the problem with a test application independently from the JSF library.
Oleg
> HttpClient JSF issue - missing line feed character causes JSF file upload parse to fail.
> ----------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1112
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1112
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpMime
> Affects Versions: 4.1.1
> Environment: Any environment.
> Reporter: Kevin Tobin
> Labels: newbie
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> We have an application that cannot read the mime multipart generated by HttpClient's HttpMime library but can read mime created by any other browser. Turns out that the only difference between the HttpClient mime multipart data is a missing linefeed at the very end of the content body.
> The end of the mime multipart should be a --\r\n, However, HttpClient outputs the carriage return character " hex 0D" but not the last line feed "hex 0A".
> We are using an IBM JSF library that could not parse the mime multipart but even worse - did not even report an error - so we spent a couple of days tracking down the problem.
> In the org.apache.http.entity.mime.HttpMultipart.java code - we can see that the class definitely writes out the last dash dash CR and LF i.e. "--\r\n" into its internal buffers... however the generated final output stream delivered across the network is one byte short - i.e. missing the linefeed. It's as if the internal Content-Length should be one byte longer.
> Our Apache File Upload code works fine with the missing linefeed generated mime data however the IBM JSF code does not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1112) HttpClient JSF issue - missing
line feed character causes JSF file upload parse to fail.
Posted by "Kevin Tobin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Tobin updated HTTPCLIENT-1112:
------------------------------------
Description:
We have an application that cannot read the mime multipart generated by HttpClient's HttpMime library but can read mime created by any other browser. Turns out that the only difference between the HttpClient mime multipart data is a missing linefeed at the very end of the content body.
The end of the mime multipart should be a --\r\n, However, HttpClient outputs the carriage return character " hex 0D" but not the last line feed "hex 0A".
We are using an IBM JSF library that could not parse the mime multipart but even worse - did not even report an error - so we spent a couple of days tracking down the problem.
In the org.apache.http.entity.mime.HttpMultipart.java code - we can see that the class definitely writes out the last dash dash CR and LF i.e. "--\r\n" into its internal buffers... however the generated final output stream delivered across the network is one byte short - i.e. missing the linefeed. It's as if the internal Content-Length should be one byte longer.
Our Apache File Upload code works fine with the missing linefeed generated mime data however the IBM JSF code does not.
was:
We have an application that cannot read the mime multipart generated by HttpClient's HttpMime library but
can read mime created by any other browser.
Turns out that the only difference between the HttpClient mime multipart data is a missing linefeed at the very end of the
the content body.
The HTTPMime Java code definitely writes out the last dash dash CR and LF i.e. "--\r\n" into its internal buffers... but the generated final output stream is one byte short.
>From a useability perspective this does not affect HTTP Client as it is able to read mime multipart missing the linefeed... but it does affect other non http lcienconsumers of the generated data,
> HttpClient JSF issue - missing line feed character causes JSF file upload parse to fail.
> ----------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1112
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1112
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpMime
> Affects Versions: 4.1.1
> Environment: Any environment.
> Reporter: Kevin Tobin
> Labels: newbie
> Fix For: 4.1.2
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> We have an application that cannot read the mime multipart generated by HttpClient's HttpMime library but can read mime created by any other browser. Turns out that the only difference between the HttpClient mime multipart data is a missing linefeed at the very end of the content body.
> The end of the mime multipart should be a --\r\n, However, HttpClient outputs the carriage return character " hex 0D" but not the last line feed "hex 0A".
> We are using an IBM JSF library that could not parse the mime multipart but even worse - did not even report an error - so we spent a couple of days tracking down the problem.
> In the org.apache.http.entity.mime.HttpMultipart.java code - we can see that the class definitely writes out the last dash dash CR and LF i.e. "--\r\n" into its internal buffers... however the generated final output stream delivered across the network is one byte short - i.e. missing the linefeed. It's as if the internal Content-Length should be one byte longer.
> Our Apache File Upload code works fine with the missing linefeed generated mime data however the IBM JSF code does not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1112) HttpClient JSF issue - missing
line feed character causes JSF file upload parse to fail.
Posted by "Kevin Tobin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079151#comment-13079151 ]
Kevin Tobin commented on HTTPCLIENT-1112:
-----------------------------------------
Hi Oleg,
I will send you a small app that demonstrates the problem.
Cheers!
Best Regards,
Kevin
Kevin Tobin
Infrastructure Solutions Designer
Infrastructure & Operations
Allianz Australia Insurance Ltd | 2 Market Street, Sydney NSW 2000
Phone: +61 2 8258 6132
eMail : kevin.tobin@allianz.com.au
Allianz - Employer of Choice for Women (EOWA) 2009 - 2011
> HttpClient JSF issue - missing line feed character causes JSF file upload parse to fail.
> ----------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1112
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1112
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpMime
> Affects Versions: 4.1.1
> Environment: Any environment.
> Reporter: Kevin Tobin
> Labels: newbie
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> We have an application that cannot read the mime multipart generated by HttpClient's HttpMime library but can read mime created by any other browser. Turns out that the only difference between the HttpClient mime multipart data is a missing linefeed at the very end of the content body.
> The end of the mime multipart should be a --\r\n, However, HttpClient outputs the carriage return character " hex 0D" but not the last line feed "hex 0A".
> We are using an IBM JSF library that could not parse the mime multipart but even worse - did not even report an error - so we spent a couple of days tracking down the problem.
> In the org.apache.http.entity.mime.HttpMultipart.java code - we can see that the class definitely writes out the last dash dash CR and LF i.e. "--\r\n" into its internal buffers... however the generated final output stream delivered across the network is one byte short - i.e. missing the linefeed. It's as if the internal Content-Length should be one byte longer.
> Our Apache File Upload code works fine with the missing linefeed generated mime data however the IBM JSF code does not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org