As mentioned in my previous email, it looks like it is safe to assume that
the release plan for HTTP Client 1.0 will be approved. Hence let's proceed
as if it is until we find out otherwise.
Per the release plan
(http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/httpclient/RELEASE_PLAN_1_0.txt)
our first task is to determine (via a lazy majority vote) the
changes/additions/removals/etc. to the Jakarta-Slide/main branch versions of
HTTP Client will be considered "in-scope" for the 1.0 release. The
intention is to have these changes identified (but not necessarily
implemented) by 23:59:59 GMT on Wednesday, 5 September 2001.
Here's a first pass toward that end. I've tried to enumerate the issues I am
aware of and what seemed to be the viable alternatives for each. If you'd
like to raise additional issues, or suggest additional alternatives, feel
free to do so. As always, non-binding votes are welcome, but only votes from
committers are significant for decision making purposes.
If you need clarification on any of the following, I'd be happy to try to
provide it.
<ballot>
1) Select one:
[ ] (a) Keep the org.apache.commons.httpclient.log package
[ ] (b) Return to stdout/stderr based logging/debugging
[ ] (c) Remove logging/debugging output altogether
2) Select one:
[ ] (a) Continue not to support multiple headers with the same
name, leaving the current behavior (second header
overwrites the first)
[ ] (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
4) Select one:
[ ] (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
5) Select one:
[ ] (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)
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)
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
[ ] (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
[ ] (c) Make HTTPS work with proxies and vice versa.
7) Select one:
[ ] (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:
[ ] (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.
[ ] (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.
[ ] (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
[ ] (b) Don't accept "secure" cookies over insecure connections
7.5) Select one:
[ ] (a) Continue to ignore secure parameter when sending
cookies
[ ] (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.
8) Select one:
[ ] (a) Continue to throw NullPointerException when
NameValuePair.equals method is invoked with a null name
or value
[ ] (b) Don't throw an exception in this case, treating
null == null.
</ballot>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
