You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Christopher BROWN <br...@reflexe.fr> on 2013/11/09 23:15:56 UTC
Some observations with HTTP Client 4.3.1
Hello,
Porting some HTTP Client 4.2 code to non-deprecated equivalents in 4.3.1, I
noticed a small change between:
// MultipartEntity
entity.addPart("field", new StringBody(values));
...and:
// MultipartEntityBuilder
entityBuilder.addTextBody("field", values);
The former, when no charset is specified, defaults to ASCII, due to:
@Deprecated
public StringBody(final String text) throws UnsupportedEncodingException {
this(text, "text/plain", Consts.ASCII);
}
The latter, without a charset, defaults to ISO-8859-1 from what I can see.
This broke a unit test in my code, but was easily fixed. I'm guessing it
makes more sense to use ISO-8859-1 because it seems to be the default in
practice on the Internet. Is that correct?
Also, I built HTTP client from source using the command:
mvn -Dmaven.compiler.target=1.7 package
...which generated class files in 1.7 format (slightly optimized if I'm to
believe Oracle/Sun docs). However, the user agent still shows
"Apache-HttpClient/4.3.1 (java 1.5)" as the User-Agent. Is it useful to
hard-code the Java version like this, because it doesn't match the compiler
option or the runtime environment?
As a side note, I'm liking the fluent API more and more!
Thanks,
Christopher
Re: Some observations with HTTP Client 4.3.1
Posted by William Speirs <ws...@apache.org>.
I'd like to chime in on the end of this... I've converted some code from
4.2.x to 4.3.x and it wasn't bad at all. I too am *loving* the fluent API.
Great job Oleg!!!
Bill-
On Sun, Nov 10, 2013 at 11:45 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
> On Sat, 2013-11-09 at 23:15 +0100, Christopher BROWN wrote:
> > Hello,
> >
> > Porting some HTTP Client 4.2 code to non-deprecated equivalents in
> 4.3.1, I
> > noticed a small change between:
> >
> > // MultipartEntity
> > entity.addPart("field", new StringBody(values));
> >
> > ...and:
> >
> > // MultipartEntityBuilder
> > entityBuilder.addTextBody("field", values);
> >
> > The former, when no charset is specified, defaults to ASCII, due to:
> >
> > @Deprecated
> > public StringBody(final String text) throws UnsupportedEncodingException
> {
> > this(text, "text/plain", Consts.ASCII);
> > }
> >
> > The latter, without a charset, defaults to ISO-8859-1 from what I can
> see.
> > This broke a unit test in my code, but was easily fixed. I'm guessing
> it
> > makes more sense to use ISO-8859-1 because it seems to be the default in
> > practice on the Internet. Is that correct?
> >
>
> Hi Christopher
>
> I do not have a reference handy, but I am fairly confident that the MIME
> spec actually defines ISO-8859-1 as the default content for textual
> content bodies. The old implementation was simply incorrect.
>
> > Also, I built HTTP client from source using the command:
> >
> > mvn -Dmaven.compiler.target=1.7 package
> >
> > ...which generated class files in 1.7 format (slightly optimized if I'm
> to
> > believe Oracle/Sun docs). However, the user agent still shows
> > "Apache-HttpClient/4.3.1 (java 1.5)" as the User-Agent. Is it useful to
> > hard-code the Java version like this, because it doesn't match the
> compiler
> > option or the runtime environment?
> >
>
> The initial intent was to state the minimal JRE compatibility level for
> HttpClient of a particular version. This has been causing a fair deal
> confusion though. The way the default user-agent id is generated is very
> likely to change in 4.4. Feel free to raise a JIRA for this issue if you
> want to keep track of its resolution.
>
> > As a side note, I'm liking the fluent API more and more!
> >
>
> I am glad to hear that. Usually such major API changes tend to generate
> more rants and outright insults than gratitude or even constructive
> criticism.
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Some observations with HTTP Client 4.3.1
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2013-11-09 at 23:15 +0100, Christopher BROWN wrote:
> Hello,
>
> Porting some HTTP Client 4.2 code to non-deprecated equivalents in 4.3.1, I
> noticed a small change between:
>
> // MultipartEntity
> entity.addPart("field", new StringBody(values));
>
> ...and:
>
> // MultipartEntityBuilder
> entityBuilder.addTextBody("field", values);
>
> The former, when no charset is specified, defaults to ASCII, due to:
>
> @Deprecated
> public StringBody(final String text) throws UnsupportedEncodingException {
> this(text, "text/plain", Consts.ASCII);
> }
>
> The latter, without a charset, defaults to ISO-8859-1 from what I can see.
> This broke a unit test in my code, but was easily fixed. I'm guessing it
> makes more sense to use ISO-8859-1 because it seems to be the default in
> practice on the Internet. Is that correct?
>
Hi Christopher
I do not have a reference handy, but I am fairly confident that the MIME
spec actually defines ISO-8859-1 as the default content for textual
content bodies. The old implementation was simply incorrect.
> Also, I built HTTP client from source using the command:
>
> mvn -Dmaven.compiler.target=1.7 package
>
> ...which generated class files in 1.7 format (slightly optimized if I'm to
> believe Oracle/Sun docs). However, the user agent still shows
> "Apache-HttpClient/4.3.1 (java 1.5)" as the User-Agent. Is it useful to
> hard-code the Java version like this, because it doesn't match the compiler
> option or the runtime environment?
>
The initial intent was to state the minimal JRE compatibility level for
HttpClient of a particular version. This has been causing a fair deal
confusion though. The way the default user-agent id is generated is very
likely to change in 4.4. Feel free to raise a JIRA for this issue if you
want to keep track of its resolution.
> As a side note, I'm liking the fluent API more and more!
>
I am glad to hear that. Usually such major API changes tend to generate
more rants and outright insults than gratitude or even constructive
criticism.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org