Besides inertial friction to a change, is there a specific reason not to
consolidate on a single http provider? We already know that people may
use the dav wagon simply to handle larger artifacts and such, it seems
like reducing our surface area here would help
I wouldn't be opposed to allowing some selection mechanism, but telling
tons of users to switch from the familiar http:// url is just going to
confuse them.
Brett Porter wrote:
On 29/04/2009, at 4:15 AM, Brett Porter wrote:
On 29/04/2009, at 1:37 AM, John Casey wrote:
I'll file the issue, but we've come across a problem where long
passwords cause Sun's Base64 implementation to line-wrap the
Authorization HTTP header.
I've done extensive testing on this in our internal code, and found
that httpclient works perfectly on the same cases.
Got it. We might want to extend the RC cycle and limit any other
changes to artifact handling to avoid question with might cause
problems.
Is it possible to add an IT for the original problem by checking the
header on the server side?
Another thing worth looking at is a config option that can flip
implementations, though it might be tricky since I think the wagons
use the same role hint.
Further option to this: we could add additional role-hints (like in
the dav wagon) so that you can choose which implementation to use in
case of problems (it'd also need to be added as an extension).
Note that your specific issue can probably be worked around by using a
dav:// URL instead of http:// on an unmodified 2.1.0.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
