> <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.
> 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
> [X] (c) Respect query string changes during redirect
>
> 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
>
I would like to minize the amount of changes for 1.0. For a later version,
although it should be mentioned in the release notes.
> 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)
>
I would like to minize the amount of changes for 1.0. For a later version,
although it should be mentioned in the release notes.
> 6) Select one:
> [ ] (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)
Dunno. I would say the easiest/fastest as apparently it is not used by
Slide.
>
> 6.1) Select one:
> [ ] (a) Continue to throw exception when a redirect is
> encountered in response to an HTTPS request
> [X] (b) Continue to throw exception, but make the message more
> explicit
> [ ] (c) Support redirects from HTTPS to HTTPS
> (also see question 5)
Either b or c, with a preference for b. Maybe we can support c in a
subsequent version (1.1 and 2.0). I don't think it is vital for a 1.0
release.
>
> 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.
>
not sure the work involved. If small then c, otherwise a
> 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
>
> 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].
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 ?
> 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
>
yes but with a policy to turn that check (see above).
> 7.5) Select one:
> [ ] (a) Continue to ignore secure parameter when sending
> cookies
> [X] (b) Don't submit "secure" cookies over insecure connections
>
same comment as for 7.4
> 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
> [X] (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:
> [X] (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.)
we can add support for other format in later versions (1.1)
>
> 7.8) Select one:
> [ ] (a) Continue to submit a "Cookie: $Version=1" header when
> cookies exist in State but none match the given request.
> [X] (b) Don't submit/add a "Cookie" header at all when Cookies
> exist in State but none match the given request.
>
> 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.
>
> </ballot>
Thanks a lot for this nice summary ! :)
I'm quite concerned by the comment I have written below question 7.2 as this
could mean Cactus would not be able to use HttpClient, which would be a
pity.
-Vincent
