><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

I've not particular opinion on this for release 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

Personally I'd consider anything but (b) or (c) a showstopper, but I'll 
defer to the team's opinion.

>4) Select one:
>[ ] (a) Continue to ignore host/port changes during redirect
>[X] (b) Throw exception when host/port changes during redirect
>[ ] (c) Support host/port changes during redirect

Personally I'd consider anything but (b) or (c) a showstopper, but I'll 
defer to the team's opinion.

>5) Select one:
>[ ] (a) Continue to ignore protocol changes during redirect
>[ ] (b) Throw exception when protocol changes during redirect
>[X] (c) Support redirects from HTTP to HTTPS, but throw an         
>exception when redirecting from HTTPS to HTTP
>         (also see question 6.1)

Personally I'd consider anything but (b) or (c) a showstopper, but I'll 
defer to the team's opinion.

>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)

(Assuming 6.1 and 6.2 can be addressed on way or another.)

>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.

>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)

(Assuming 7.x can be addressed, otherwise just drop it.)

>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
>
>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

Personally I'd consider anything but (b) a showstopper, but I'll defer to 
the team's opinion.


>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:
>[ ] (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.)

I've no opinion for release 1.0.

>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>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Reply via email to