> <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
It's not really up for vote, as I had vetoed that change (that got ignored,
which is another story).
Also, it's purely debugging, as logging was supposed to be done through the
interceptor mechanism, which will get documented a lot better eventually.
I think reverting this for 1.0 was relatively well agreed upon.
> 2) Select one:
> [ ] (a) Continue not to support multiple headers with the same
> name, leaving the current behavior (second header
> overwrites the first)
> [X] (b) Support multiple headers with the same name
> (i.e., when headers like "a: one" and "a: two"
> are received, treat as "a: one, two")
>
> 3) Select one:
> [ ] (a) Continue to ignore query string changes during redirect
> [ ] (b) Throw an exception for query string changes during redirect
> [ ] (c) Respect query string changes during redirect
I didn't encounter the problem, and would need an example to better
understand the problem.
> 4) Select one:
> [X] (a) Continue to ignore host/port changes during redirect
> [ ] (b) Throw exception when host/port changes during redirect
> [ ] (c) Support host/port changes during redirect
Cross servers redirects can be supported in 2.x only, IMO.
I think it's a bit dangerous to do that automatically ...
> 5) Select one:
> [X] (a) Continue to ignore protocol changes during redirect
> [ ] (b) Throw exception when protocol changes during redirect
> [ ] (c) Support redirects from HTTP to HTTPS, but throw an
> exception when redirecting from HTTPS to HTTP
> (also see question 6.1)
That's a useful feature, but I would do it in 2.x only.
> 6) Select one:
> [X] (a) Retain support for HTTPS, possibly addressing the
> following issues
> (If selected, continue with questions 6.x)
> [ ] (b) Drop support for HTTPS
> (If selected, skip to question 7)
SSL is useful for WebDAV. I never complained when you added it, except that
it did add a dependency on JSSE.
> 6.1) Select one:
> [ ] (a) Continue to throw exception when a redirect is
> encountered in response to an HTTPS request
> [ ] (b) Continue to throw exception, but make the message more
> explicit
> [X] (b) Support redirects from HTTPS to HTTPS
> (also see question 5)
>
> 6.2) Select one:
> [ ] (a) Continue to ignore HTTPS/secure parameter when
> proxying.
> [ ] (b) Drop support for proxies altogether
> [X] (c) Make HTTPS work with proxies and vice versa.
Although it's best effort here.
> 7) Select one:
> [X] (a) Continue to support cookies, possibly addressing the
> following issues
> (If selected, continue with questions 7.x)
> [ ] (b) Drop support for cookies.
> (If selected, skip to question 8)
>
> 7.1) Select one:
> [X] (a) Correct Cookie.isToBeDiscarded() (currently returns
> false for true/true for false)
> [ ] (b) Leave Cookie.isToBeDiscarded() alone
I don't exactly know what hgas to be fix. Will backport the fix.
> 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
>
> 7.3) Select one:
> [ ] (a) Continue to send "secure" parameter when submitting
> cookies.
> [X] (b) Don't send "secure" parameter when submitting cookies
> (per RFC 2109)
>
> 7.4) Select one:
> [ ] (a) Continue to ignore secure parameter when accepting
> cookies
> [X] (b) Don't accept "secure" cookies over insecure connections
>
> 7.5) Select one:
> [ ] (a) Continue to ignore secure parameter when sending
> cookies
> [X] (b) Don't submit "secure" cookies over insecure connections
>
> 7.6) Select one:
> [ ] (a) Continue to default to null for path attribute when
> a cookie without any "extra" parameter (domain, max-age,
> comment, etc.) is received, but default to "/" when
> at least one "extra" parameter is received.
> [ ] (b) Make path attribute default to "/" in all cases for
> which no path parameter is returned in the set-cookie
> header
> [ ] (c) Make path attribute default to directory/path of request
> in all cases for which no path parameter is returned
> in the set-cookie header, per RFC 2109
>
> 7.7) Select one:
> [ ] (a) Continue to accept only the specific RFC 2109 format
> for "expires" attribute of cookies
> [ ] (b) Accept some additional "expires" date formats, as
> returned by Catalina and other servers (optional comma,
> y2k friendly years, etc.)
>
> 7.8) Select one:
> [ ] (a) Continue to submit a "Cookie: $Version=1" header when
> cookies exist in State but none match the given request.
> [ ] (b) Don't submit/add a "Cookie" header at all when Cookies
> exist in State but none match the given request.
These will require very limited API changes, for which I'm +1. I never read
RFC 2109, so I'll backport the relevant patches.
I'm +1 to delay these fixes until a 1.1 maintenance release, though.
Thanks for summarizing the issues.
> 8) Select one:
> [ ] (a) Continue to throw NullPointerException when
> NameValuePair.equals method is invoked with a null name
> or value
> [X] (b) Don't throw an exception in this case, treating
> null == null.
That's a very simple fix :)
> </ballot>
Also, it is almost certain that I will add support for digest authentication
in 1.x (let's say in 1.1). It shouldn't be too difficult to also add the
feature to the 2.x branch at the same time.
Remy
