You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by jd...@apache.org on 2009/06/23 00:56:26 UTC
svn commit: r787433 -
/maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Author: jdcasey
Date: Mon Jun 22 22:56:25 2009
New Revision: 787433
URL: http://svn.apache.org/viewvc?rev=787433&view=rev
Log:
Adding documentation for (proposed) new httpclient-based wagon configuration.
Added:
maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt (with props)
Added: maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt?rev=787433&view=auto
==============================================================================
--- maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt (added)
+++ maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt Mon Jun 22 22:56:25 2009
@@ -0,0 +1,346 @@
+ ------
+ Guide to HTTP Wagon Configuration
+ ------
+ John Casey
+ ------
+ 22 June 2009
+ ------
+
+Configuring the HTTP Wagon
+
+ <<NOTE:>> This feature is available in <<Maven 2.2.0>> and later.
+
+ Since the introduction of the HttpClient\[1\]-based HTTP Wagon as the default for Maven 2.2.0 and above, you have a lot more control over the
+ configuration used to access HTTP-based Maven repositories. For starters, you have fine-grained control over what HTTP headers
+ are used when resolving artifacts. In addition, you can also configure a wide range of parameters to control the behavior
+ of HttpClient itself. Best of all, you have the ability to control these headers and parameters for all requests, or individual
+ request types (Maven issues GET, HEAD, and PUT requests for different parts of the artifact-management subsystem).
+
+*The Basics
+
+ Without any special configuration, Maven's HTTP wagon will use some default HTTP headers and client parameters when managing
+ artifacts. The default headers are:
+
++---+
+Cache-control: no-cache
+Cache-store: no-store
+Pragma: no-cache
+Expires: 0
+Accept-Encoding: gzip
++---+
+
+ In addition, PUT requests made with the HTTP wagon will use the following HttpClient parameter:
+
++---+
+http.protocol.expect-continue=true
++---+
+
+ From the HttpClient documentation\[2\], this parameter provides the following functionality:
+
+-----
+Activates 'Expect: 100-Continue' handshake for the entity enclosing methods.
+The 'Expect: 100-Continue' handshake allows a client that is sending a request
+message with a request body to determine if the origin server is willing to
+accept the request (based on the request headers) before the client sends the
+request body.
+
+The use of the 'Expect: 100-continue' handshake can result in noticeable performance
+improvement for entity enclosing requests (such as POST and PUT) that require
+the target server's authentication.
+
+'Expect: 100-continue' handshake should be used with caution, as it may cause
+problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
+-----
+
+ Without this setting, PUT requests that require authentication will transfer their entire payload to the server before that server
+ issues an authentication challenge. In order to complete the PUT request, the client must then re-send the payload with the proper
+ credentials specified in the HTTP headers. This results in twice the bandwidth usage, and twice the time to transfer each artifact.
+
+ Another option to avoid this double transfer is what's known as preemptive authentication, which involves sending the authentication
+ headers along with the original PUT request. However, there are a few potential issues with this approach. For one thing, in the event
+ you have an unused <<<\<server\>>>> entry that specifies an invalid username/password combination, some servers may respond with
+ a <<<401 Unauthorized>>> even if the server doesn't actually require any authentication for the request. In addition, blindly sending
+ authentication credentials with every request regardless of whether the server has made a challenge can result in a security hole,
+ since the server may not make provisions to secure credentials for paths that don't require authentication.
+
+ We'll discuss preemptive authentication in another example, below.
+
+*Configuring GET, HEAD, PUT, or All of the Above
+
+ In all of the examples below, it's important to understand that we can configure the HTTP settings for all requests made to a given
+ server, or for only one method. To configure all methods for a server, you'd use the following section of the <<<settings.xml>>> file:
+
++---+
+<settings>
+ [...]
+ <servers>
+ <server>
+ <id>the-server</id>
+ <configuration>
+ <httpConfiguration>
+ <all>
+ [ Your configuration here. ]
+ </all>
+ </httpConfiguration>
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+ On the other hand, if you can live with the default configuration for most requests - say, HEAD and GET requests, which are used to
+ check for the existence of a file and retrieve a file respectively - maybe you only need to configure the PUT method:
+
++---+
+<settings>
+ [...]
+ <servers>
+ <server>
+ <id>the-server</id>
+ <configuration>
+ <httpConfiguration>
+ <put>
+ [ Your configuration here. ]
+ </put>
+ </httpConfiguration>
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+ For clarity, the other two sections are <<<\<get\>>>> for GET requests, and <<<\<head\>>>> for HEAD requests. I know that's going to
+ be hard to remember...
+
+*Taking Control of Your HTTP Headers
+
+ As you may have noticed above, the default HTTP headers do have the potential to cause problems. For instance, some websites
+ set the encoding for downloading GZipped files as <<<gzip>>>, in spite of the fact that the HTTP request itself isn't being
+ sent using GZip compression. If the client is using the <<<Accept-Encoding: gzip>>> header, this can result in the client itself
+ decompressing the GZipped file <during the transfer> and writing the decompressed file to the local disk with the original filename.
+ This can be misleading to say the least, and can use up an inordinate amount of disk space on the local computer.
+
+ To turn off this default behavior, we'll simply disable the default headers. Then, we'll need to respecify the other headers
+ that we are still interested in, like this:
+
++---+
+<settings>
+ [...]
+ <servers>
+ <server>
+ <id>openssl</id>
+ <configuration>
+ <httpConfiguration>
+ <put>
+ <useDefaultHeaders>false</useDefaultHeaders>
+ <headers>
+ <header>
+ <name>Cache-control</name>
+ <value>no-cache</value>
+ </header>
+ <header>
+ <name>Cache-store</name>
+ <value>no-store</value>
+ </header>
+ <header>
+ <name>Pragma</name>
+ <value>no-cache</value>
+ </header>
+ <header>
+ <name>Expires</name>
+ <value>0</value>
+ </header>
+ <header>
+ <name>Accept-Encoding</name>
+ <value>*</value>
+ </header>
+ </headers>
+ </put>
+ </httpConfiguration>
+ </configuration>
+ </server>
+ [...]
+ </servers>
+ [...]
+</settings>
++---+
+
+*Fine-Tuning HttpClient Parameters
+
+ Going beyond the power of HTTP request parameters, HttpClient provides a host of other configuration options. In most cases,
+ you won't need to customize these. But in case you do, Maven provides access to specify your own fine-grained configuration
+ for HttpClient. Again, you can specify these parameter customizations per-method (HEAD, GET, or PUT), or for all methods of
+ interacting with a given server. For a complete list of supported parameters, see the link\[2\] in Resources section below.
+
+**Non-String Parameter Values
+
+ Many of the configuration parameters for HttpClient have simple string values; however, there are important exceptions to
+ this. In some cases, you may need to specify boolean, integer, or long values. In others, you may even need to specify
+ a collection of string values. You can specify these using a simple formatting syntax, as follows:
+
+ [[1]] <<booleans:>> <<<%b,\<value\>>>>
+
+ [[2]] <<integer:>> <<<%i,\<value\>>>>
+
+ [[3]] <<long:>> <<<%l,\<value\>>>> (yes, that's an 'L', not a '1')
+
+ [[4]] <<double:>> <<<%d,\<value\>>>>
+
+ [[5]] <<collection of strings:>> <<<%c,\<value1\>,\<value2\>,\<value3\>,...>>>, which could also be specified as:
+
++---+
+%c,
+<value1>,
+<value2>,
+<value3>,
+...
++---+
+
+ []
+
+ As you may have noticed, this syntax is similar to the format-and-data strategy used by functions like <<<sprintf()>>>
+ in many languages. The syntax has been chosen with this similarity in mind, to make it a little more intuitive to use.
+
+**Example: Using Preemptive Authentication
+
+ Using the above syntax, we can configure preemptive authentication for PUT requests using the boolean HttpClient parameter
+ <<<http.authentication.preemptive>>>, like this:
+
++---+
+<settings>
+ <servers>
+ <server>
+ <id>my-server</id>
+ <configuration>
+ <httpConfiguration>
+ <put>
+ <params>
+ <param>
+ <name>http.authentication.preemptive</name>
+ <value>%b,true</value>
+ </param>
+ </params>
+ </put>
+ </httpConfiguration>
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+**Ignoring Cookies
+
+ Like the example above, telling the HttpClient to ignore cookies for all methods of request is a simple matter of
+ configuring the <<<http.protocol.cookie-policy>>> parameter (it uses a regular string value, so no special syntax
+ is required):
+
++---+
+<settings>
+ <servers>
+ <server>
+ <id>my-server</id>
+ <configuration>
+ <httpConfiguration>
+ <all>
+ <params>
+ <param>
+ <name>http.protocol.cookie-policy</name>
+ <value>ignore</value>
+ </param>
+ </params>
+ </all>
+ </httpConfiguration>
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+ The configuration above can be useful in cases where the repository is using cookies - like the session cookies
+ that are often mistakenly turned on or left on in appservers - alongside HTTP redirection. In these cases, it
+ becomes far more likely that the cookie issued by the appserver will use a <<<Path>>> that is inconsistent with
+ the one used by the client to access the server. If you have this problem, and know that you don't need to use
+ this session cookie, you can ignore cookies from this server with the above configuration.
+
+*Deprecation Notes
+
+ It should be noted that configuration options previously available in the HttpClient-driven HTTP wagon have been
+ deprecated in favor of this more general, fine-grained approach. These include the configuration of HTTP headers
+ and connection timeouts. Let's examine each of these briefly:
+
+**HTTP Headers
+
+ Previously, you could add your own HTTP headers to the HttpClient-based wagon like this:
+
++---+
+<settings>
+ <servers>
+ <server>
+ <id>my-server</id>
+ <configuration>
+ <httpHeaders>
+ <httpHeader>
+ <name>Foo</name>
+ <value>Bar</value>
+ </httpHeader>
+ </httpHeaders>
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+ It's important to understand that the above method didn't allow you to turn off the default HTTP headers; nor
+ did it allow you to specify headers on a per-method basis.
+
+**Connection Timeouts
+
+ All wagon implementations that extend the <<<AbstractWagon>>> class, including those for SCP, HTTP, FTP, and more,
+ allow the configuration of a connection timeout, to allow the user to tell Maven how long to wait before giving
+ up on a connection that has not responded. This option is preserved in the HttpClient-based wagon, but this wagon
+ also provides a fine-grained alternative configuration that can allow you to specify timeouts per-method for a
+ given server. The old configuration option - which is still supported - looks like this:
+
++---+
+<settings>
+ <servers>
+ <server>
+ <id>my-server</id>
+ <configuration>
+ <timeout>6000</timeout> <!-- milliseconds -->
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+ ...while the new configuration option looks more like this:
+
++---+
+<settings>
+ <servers>
+ <server>
+ <id>my-server</id>
+ <configuration>
+ <httpConfiguration>
+ <put>
+ <connectionTimeout>10000</connectionTimeout> <!-- milliseconds -->
+ </put>
+ </httpConfiguration>
+ </configuration>
+ </server>
+ </servers>
+</settings>
++---+
+
+ If all you need is a per-server timeout configuration, you still have the option to use the old <<<\<timeout\>>>>
+ parameter. If you need to separate timeout preferences according to HTTP method, you can use one more like that
+ specified directly above.
+
+*Resources
+
+ [[1]] {{{http://hc.apache.org/httpclient-3.x/}HttpClient website}}
+
+ [[2]] {{{http://hc.apache.org/httpclient-3.x/preference-api.html}HttpClient preference architecture and configuration guide}}
+
+ []
Propchange: maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
------------------------------------------------------------------------------
svn:eol-style = native
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by John Casey <jd...@commonjava.org>.
Okay, I'll correct the doc. I guess I'll need to look into the
User-Agent behavior more carefully to determine what's going on there.
-john
Brett Porter wrote:
>
> On 30/06/2009, at 1:32 AM, John Casey wrote:
>
>>
>> I'm guessing User-Agent needs to be documented as an exception, since
>> we setup User-Agent through the DefaultWagonManager (IIRC, you and I
>> worked on that for 2.1.0). I'm sure the logic in DefaultWagonManager
>> overrides what you setup above.
>
> Odd that it works with httpHeaders but not the other. I haven't had a
> chance to confirm other headers are working properly.
>>
>>>> + If all you need is a per-server timeout configuration, you still
>>>> have the option to use the old <<<\<timeout\>>>>
>>>> + parameter. If you need to separate timeout preferences according
>>>> to HTTP method, you can use one more like that
>>>> + specified directly above.
>>> Do you think instead of deprecating the old httpHeaders/useCache that
>>> it could be the same recommendation? Basically - you can keep using
>>> the direct config, but if you need fine-grained the above is
>>> available. This also helps avoid issues where the lightweight vs
>>> httpclient configs have now diverged.
>>
>> Sure, I don't see what it'd hurt to remove the deprecation on
>> httpHeaders. Since deprecation of that field isn't evident for most
>> Maven users (those who are configuring the wagon via settings.xml), I
>> suppose this could wait until the beta-7 / 1.0 release?
>
> Yep, I think it was more how it would be viewed in this doc...
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by Brett Porter <br...@apache.org>.
On 30/06/2009, at 1:32 AM, John Casey wrote:
>
> I'm guessing User-Agent needs to be documented as an exception,
> since we setup User-Agent through the DefaultWagonManager (IIRC, you
> and I worked on that for 2.1.0). I'm sure the logic in
> DefaultWagonManager overrides what you setup above.
Odd that it works with httpHeaders but not the other. I haven't had a
chance to confirm other headers are working properly.
>
>>> + If all you need is a per-server timeout configuration, you
>>> still have the option to use the old <<<\<timeout\>>>>
>>> + parameter. If you need to separate timeout preferences
>>> according to HTTP method, you can use one more like that
>>> + specified directly above.
>> Do you think instead of deprecating the old httpHeaders/useCache
>> that it could be the same recommendation? Basically - you can keep
>> using the direct config, but if you need fine-grained the above is
>> available. This also helps avoid issues where the lightweight vs
>> httpclient configs have now diverged.
>
> Sure, I don't see what it'd hurt to remove the deprecation on
> httpHeaders. Since deprecation of that field isn't evident for most
> Maven users (those who are configuring the wagon via settings.xml),
> I suppose this could wait until the beta-7 / 1.0 release?
Yep, I think it was more how it would be viewed in this doc...
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by John Casey <jd...@commonjava.org>.
Brett Porter wrote:
>
> On 23/06/2009, at 8:56 AM, jdcasey@apache.org wrote:
>
>> Author: jdcasey
>> Date: Mon Jun 22 22:56:25 2009
>> New Revision: 787433
>>
>> URL: http://svn.apache.org/viewvc?rev=787433&view=rev
>> Log:
>> Adding documentation for (proposed) new httpclient-based wagon
>> configuration.
>>
>> Added:
>> maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
>> (with props)
>>
> [...]
>
> John,
>
> I found the following configuration didn't work with 2.2.0:
>
> <servers>
> <server>
> <id>localhost</id>
> <configuration>
> <httpConfiguration>
> <get>
> <useDefaultHeaders>false</useDefaultHeaders>
> <headers>
> <header>
> <name>User-Agent</name>
> <value>Foo-Bar/1.1</value>
> </header>
> </headers>
> </get>
> </httpConfiguration>
>
> (I also tried without the default headers line, and with "all" instead
> of "get").
>
> <httpHeaders/> continues to work.
>
> What am I doing wrong?
I'm guessing User-Agent needs to be documented as an exception, since we
setup User-Agent through the DefaultWagonManager (IIRC, you and I worked
on that for 2.1.0). I'm sure the logic in DefaultWagonManager overrides
what you setup above.
>
>> + It's important to understand that the above method didn't allow you
>> to turn off the default HTTP headers; nor
>> + did it allow you to specify headers on a per-method basis.
>
> That's not quite true, since the only default headers were the caching
> ones, which could be disabled by setting useCache to false. Would it be
> better to phrase this as "under 2.1.0 and earlier"?
I was actually referring to Accept-Encoding, which came up in one of the
WAGON issues for the -beta-6 release. From what I could tell, useCache
== false doesn't/shouldn't turn that header off...
>
>> + If all you need is a per-server timeout configuration, you still
>> have the option to use the old <<<\<timeout\>>>>
>> + parameter. If you need to separate timeout preferences according to
>> HTTP method, you can use one more like that
>> + specified directly above.
>
> Do you think instead of deprecating the old httpHeaders/useCache that it
> could be the same recommendation? Basically - you can keep using the
> direct config, but if you need fine-grained the above is available. This
> also helps avoid issues where the lightweight vs httpclient configs have
> now diverged.
Sure, I don't see what it'd hurt to remove the deprecation on
httpHeaders. Since deprecation of that field isn't evident for most
Maven users (those who are configuring the wagon via settings.xml), I
suppose this could wait until the beta-7 / 1.0 release?
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by Brett Porter <br...@apache.org>.
On 30/06/2009, at 10:42 AM, John Casey wrote:
> Well, in any case, see my changes to that document if you
> want...I've removed references to deprecated configuration, and
> termed it more of a general-case configuration option instead.
Looks good to me - thanks!
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by John Casey <jd...@commonjava.org>.
Well, in any case, see my changes to that document if you want...I've
removed references to deprecated configuration, and termed it more of a
general-case configuration option instead.
Brett Porter wrote:
>
> On 30/06/2009, at 10:16 AM, John Casey wrote:
>
>>
>>
>> Brett Porter wrote:
>>>> + It's important to understand that the above method didn't allow
>>>> you to turn off the default HTTP headers; nor
>>>> + did it allow you to specify headers on a per-method basis.
>>> That's not quite true, since the only default headers were the
>>> caching ones, which could be disabled by setting useCache to false.
>>> Would it be better to phrase this as "under 2.1.0 and earlier"?
>>
>>
>> BTW, maybe I'm missing something, but I took a look at the sources in
>> the beta-5 tag, and this is what I found, starting
>> AbstractHttpClientWagon.java@400 :
>
> Yay consistency :) It turns out only the lightweight one had the
> useCache flag.
>
> Anyway, you can ignore the comment, as you pointed out there was also
> the Accept-Encoding which couldn't be disabled in either.
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by Brett Porter <br...@apache.org>.
On 30/06/2009, at 10:16 AM, John Casey wrote:
>
>
> Brett Porter wrote:
>>> + It's important to understand that the above method didn't allow
>>> you to turn off the default HTTP headers; nor
>>> + did it allow you to specify headers on a per-method basis.
>> That's not quite true, since the only default headers were the
>> caching ones, which could be disabled by setting useCache to false.
>> Would it be better to phrase this as "under 2.1.0 and earlier"?
>
>
> BTW, maybe I'm missing something, but I took a look at the sources
> in the beta-5 tag, and this is what I found, starting
> AbstractHttpClientWagon.java@400 :
Yay consistency :) It turns out only the lightweight one had the
useCache flag.
Anyway, you can ignore the comment, as you pointed out there was also
the Accept-Encoding which couldn't be disabled in either.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by John Casey <jd...@commonjava.org>.
Brett Porter wrote:
>> + It's important to understand that the above method didn't allow you
>> to turn off the default HTTP headers; nor
>> + did it allow you to specify headers on a per-method basis.
>
> That's not quite true, since the only default headers were the caching
> ones, which could be disabled by setting useCache to false. Would it be
> better to phrase this as "under 2.1.0 and earlier"?
>
BTW, maybe I'm missing something, but I took a look at the sources in
the beta-5 tag, and this is what I found, starting
AbstractHttpClientWagon.java@400 :
protected int execute( HttpMethod httpMethod ) throws
HttpException, IOException
{
int statusCode = SC_NULL;
httpMethod.getParams().setSoTimeout( getTimeout() );
setHeaders( httpMethod );
statusCode = client.executeMethod( httpMethod );
return statusCode;
}
protected void setHeaders( HttpMethod method )
{
// TODO: merge with the other headers and have some better
defaults, unify with lightweight headers
method.addRequestHeader( "Cache-control", "no-cache" );
method.addRequestHeader( "Cache-store", "no-store" );
method.addRequestHeader( "Pragma", "no-cache" );
method.addRequestHeader( "Expires", "0" );
method.addRequestHeader( "Accept-Encoding", "gzip" );
if ( httpHeaders != null )
{
for ( Iterator i = httpHeaders.keySet().iterator();
i.hasNext(); )
{
String header = (String) i.next();
method.addRequestHeader( header,
httpHeaders.getProperty( header ) );
}
}
}
I think I must be missing something; how can the above code respond to a
useCache == false setting? Or is the useCache configuration a
post-beta-5 feature that hadn't been released yet?
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r787433 - /maven/site/trunk/src/site/apt/guides/mini/guide-http-settings.apt
Posted by Brett Porter <br...@apache.org>.
On 23/06/2009, at 8:56 AM, jdcasey@apache.org wrote:
> Author: jdcasey
> Date: Mon Jun 22 22:56:25 2009
> New Revision: 787433
>
> URL: http://svn.apache.org/viewvc?rev=787433&view=rev
> Log:
> Adding documentation for (proposed) new httpclient-based wagon
> configuration.
>
> Added:
> maven/site/trunk/src/site/apt/guides/mini/guide-http-
> settings.apt (with props)
>
[...]
John,
I found the following configuration didn't work with 2.2.0:
<servers>
<server>
<id>localhost</id>
<configuration>
<httpConfiguration>
<get>
<useDefaultHeaders>false</useDefaultHeaders>
<headers>
<header>
<name>User-Agent</name>
<value>Foo-Bar/1.1</value>
</header>
</headers>
</get>
</httpConfiguration>
(I also tried without the default headers line, and with "all" instead
of "get").
<httpHeaders/> continues to work.
What am I doing wrong?
> + It's important to understand that the above method didn't allow
> you to turn off the default HTTP headers; nor
> + did it allow you to specify headers on a per-method basis.
That's not quite true, since the only default headers were the caching
ones, which could be disabled by setting useCache to false. Would it
be better to phrase this as "under 2.1.0 and earlier"?
> + If all you need is a per-server timeout configuration, you still
> have the option to use the old <<<\<timeout\>>>>
> + parameter. If you need to separate timeout preferences according
> to HTTP method, you can use one more like that
> + specified directly above.
Do you think instead of deprecating the old httpHeaders/useCache that
it could be the same recommendation? Basically - you can keep using
the direct config, but if you need fine-grained the above is
available. This also helps avoid issues where the lightweight vs
httpclient configs have now diverged.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org