> >>[logging stuff]
> >It's not really up for vote, as I had vetoed that
> >change
>
> Not according to this:
>
http://www.mail-archive.com/jakarta-commons@jakarta.apache.org/msg02778.html
,
> but it doesn't really matter. I had presumed we'd want to remove it
(that's
> why I put it on the ballot), and I see no reason to believe the vote will
go
> any other way.
Yes, since you had showed that you wouldn't care about a veto anyway, I had
agreed with the change to try to reach a compromise.
The idea is to start with the tree in its pre-logging state, and then start
to selectively apply patches until all major issues are addressed.
> >>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.
>
> Suppose you submit:
>
> GET /old?query=hotdog HTTP/1.1
> Host: www.example.tld
>
> and get back in response:
>
> HTTP/1.1 302 Found
> Location: http://another.example.tld:8080/new?q=hotdog
> ^^^^^^^ ^^^^^ ^^^^^^^^^
>
> then starting with the intitial import into commons, up to and including
the
> latest revision on the main branch, HTTP Client will submit a second
request
> like:
>
> GET /new?query=hotdog HTTP/1.1
> ^^^^^^^^^^^^^
> Host: www.example.tld
> ^^^
>
> (without the ^'s, of course).
>
> So,
> (1) *only* the path changes when a redirect response is encountered and
> (2) *only* the change in path is even acknowledged (it's not just that we
> don't support things like host/port/query string changes, we don't even
> *notice* them, so that HTTP Client will blindly submit a request rather
> different from what either the client or the server had intended.)
Ok.
Remy
