> > <ballot>
> >
> > 1) Select one:
> > [ ] (a) Keep the org.apache.commons.httpclient.log package
> > [X] (b) Return to stdout/stderr based logging/debugging
> > [ ] (c) Remove logging/debugging output altogether
> >
>
> Just to please Remy ... :-) ... as this is what we agreed for 1.0. Of
> course, I find this very wrong and hope it will be corrected ASAP *after*
> version 1.0.
As I've said 200 times, the Sys.outs are debugging only, and I may remove
them altogether, because the interceptor mechanism should be used for
logging / debugging.
> > 7.2) Select one:
> > [ ] (a) Continue to ignore the request path when accepting
> > cookies.
> > [X] (b) Pay attention to request path when accepting cookies,
> > per RFC 2109
> >
>
> Pesonnally I would like to be able to set a policy for cookie handling.
One
> that would not make any verification in regards to domain and path and one
> that would. This is a global requirements that I would like for HttpClient
:
> to be able to set flags so that it acts as a pass-through. For example, we
> should have a way to tell httpclient to ignore HTTP redirects (it exists
> already). Same for cookies and all other kind of logic. [For example,
Cactus
> is a unit test framework and the user should be able to assert the http
> status code - redirect - and it should not go and download another page].
Instead of adding some complex mechanism, I was also planning to use the
interceptors here.
For example, in connection interceptor, there is :
/**
* Retry.
*
* @return boolean true if a retry should be attempted
*/
public boolean retry(int status);
(Retrurning false won't do anything now, as it is not implemented yet, but
it wil be eventually)
The point for me with the HTTP client is not to create a huge beast with
lots of complex features, but a more lightweight client (one that would also
be useful on the server side).
So I'm more interested by the "integrability" of the client, rather by it's
ability to operate standalone.
> Let's come back to cookies...
>
> The URL that is called is the Cactus proxy servlet (for example:
> http://localhost:8080/...). However, the servlet to test should be under
the
> impression the request URL was what it expects, for example :
> http://jakarta.apache.org/... Currently we do this by calling a setURL()
> method in which the user tell the test case the URL to simulate, i.e.
> HttpServletRequest.getQueryString() and al. will return parts of the
> simulated URL instead of the proxy one.
>
> At the current time we use (in Cactus) httpclient to manage cookies but
> HttpURLConnection for the connection and we manually call
> Cookie.createCookieHeader(domain, path, cookies) so we are able to set the
> domain to be the host defined in setURL(). However, when we switch to
> httpclient for managing the connection, we will loose that control as it
> will be httpclient that will make the call to createCookieHeader().
>
> So we need a way to :
> * either be able to override the domain/path,
> * turn off verification
>
> any other solution ?
We can keep the complex cookie features for 2.0. It would save me some time.
Remy
