DO NOT REPLY [Bug 10809] - Developer documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809

Developer documentation





--- Additional Comments From [EMAIL PROTECTED]  2003-03-08 04:07 ---
I've attached the latest revision of docs for review, this is now very nearly 
complete, with just the character encoding guide to be added.  Links have been 
checked with the maven link-check plugin but the docs haven't been fully proof 
read yet.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10809] - Developer documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809

Developer documentation





--- Additional Comments From [EMAIL PROTECTED]  2003-03-08 04:05 ---
Created an attachment (id=5226)
Latest revision of docs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12798] - Path should not be encoded in HttpMethodBase

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12798

Path should not be encoded in HttpMethodBase





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 23:13 ---
This patch doesn't look right to me. I'm no expert but have just recently had 
to review our URL encoding code so it concerns me that we don't seem to be 
encoding the query string.  RFC 1738 (Uniform Resource Locators), specifies 
that:

   Octets must be encoded if they have no corresponding graphic
   character within the US-ASCII coded character set, if the use of the
   corresponding character is unsafe, or if the corresponding character
   is reserved for some other interpretation within the particular URL
   scheme.

The unsafe characters listed in the rfc are:
"{", "}", "|", "\", "^", "~",
   "[", "]", "`", "<", ">", """, "#", "%"

in addition the reserved characters are:
";", "/", "?", ":", "@", "=" and "&"

It then adds:
   Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL.

   On the other hand, characters that are not required to be encoded
   (including alphanumerics) may be encoded within the scheme-specific
   part of a URL, as long as they are not being used for a reserved
   purpose.

Now, what this implies to me is that the process for encoding any given URL is:

1. Break the URL into it's various parts, for HTTP this would be:
http://:/?

2. Take each part of the URL and encode it (though one would hope that a host 
name contains only US-ASCII characters or the DNS system is going to have 
trouble with it anyway).

3. Reassemble the URL.

Now, I'm somewhat unsure as to whether the URL we are given is encoded or not 
and the JavaDocs for the methods do not specify this.  So the first action 
item of this bug must be to decide whether methods should be passed an encoded 
or an unencoded URL and document it.

IF we decide that URLs passed into the methods should be encoded, then we need 
to stop encoding the path, on the other hand, IF we decide that URLs passed 
into the methods should be unencoded, then we need to encode the query string 
as well.

Also, if all URLs are being passed in encoded, then we should have no need for 
URL encoding functionality as we should only ever use encoded URLs.

My suggestion would be to only ever work with encoded URLs, but then do one of 
the following:

1. add a new constructor to each of the methods which takes a boolean to 
determine whether the URL is encoded or not.  If not we encode it before 
passing it through to anywhere else.

2. provide the URIUtils class (possibly as a separate project) to allow the 
user to easily encode URLs.  We should ensure that there is a method in 
URIUtils that can take a full URL with non displayable US-ASCII characters and 
unsafe characters (but no extra reserved characters) and encode it correctly.  
This prevents the user having to break up the URL to encode it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: post redirect

[mathis]

David,
yes it's what I experienced: After executing a POST the browsers reads the
redirect headers (usually "Location", somtimes "Refresh") and executes a GET
to this location. 
That's all.

Thomas

-Ursprüngliche Nachricht-
Von: David Kavanagh [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 19:58
An: Commons HttpClient Project
Betreff: Re: AW: post redirect


Thomas,
I'd like to hear more about this because I don't understand how the 
browser can do that. I know if the form requires POST, the browser 
simply can't issue GET and expect it to work. Hmm, are you saying that 
the browser just looks in the response header and issues a GET to follow 
the redirect? OK, I would expect something along those lines

David

[EMAIL PROTECTED] wrote:

>I am with you Oleg! Some times ago I had the same "problem" but it figured
>out that the browsers follow the redirects not within the PostMethod but
>they instead execute a GetMethod. If they wouldn't do so the client could
>have an wrong url "displayed".
>
>Gtx,
>Thomas
>
>-Ursprüngliche Nachricht-
>Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
>Gesendet: Freitag, 7. März 2003 17:39
>An: Commons HttpClient Project
>Betreff: RE: post redirect
>
>
>David
>
>HttpClient is a library, whereas a browser is a totally different kind of
>beast.
>
>RFC 2616 says the following:
>
>"...
>   If the 301 status code is received in response to a request other
>   than GET or HEAD, the user agent MUST NOT automatically redirect the
>   request unless it can be confirmed by the user, since this might
>   change the conditions under which the request was issued
>..."
>
>A well-behaving browser should provide the end user with a confirmation
>dialog or a configuration option to automatically perform POST redirects.
>HttpClient can't have that luxury, as it is not supposed to be directly
>interacting with the end user. I am personally convinced that POST redirect
>should be handled by the application that consumes Httpclient's services.
>All it basically takes is a retry loop
>
>Does anyone see that differently?
>
>Cheers
>
>Oleg
>
>
>-Original Message-
>From: David Kavanagh [mailto:[EMAIL PROTECTED]
>Sent: Freitag, 7. März 2003 17:24
>To: [EMAIL PROTECTED]
>Subject: post redirect
>
>
>I've been working with httpclient for a couple of days to build a Cocoon 
>transformer that helps me build pipelines to navigate web sites and 
>extract data. I've read the parts of RFC2616 that deal with redirects 
>and state they are automatic on the client only for GET and HEAD 
>methods. I know the JDC and a web site I wrote use POST for the login 
>form and issue a redirect as a response. Any browser I've tried this 
>with honors the redirect. I can send some test code I've been using to 
>test the automated login (that includes handling cookies).
>Anyway, I've observed browsers honoring the redirect on a POST, can't 
>httpclient be configured that way? Looking at the source code tells me 
>no. (I've been using 2.0 alpha 3).
>
>Thanks,
>David
>
>-
>To unsubscribe, e-mail:
[EMAIL PROTECTED]
>For additional commands, e-mail:
[EMAIL PROTECTED]
>  
>



-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: post redirect

[Oleg Kalnichevski]

David

I think it is exactly the case. Any sane browser should avoid blindly
redirecting POST request for security reason and should issue GET
request instead expecting to receive a new form to be filled out and
only then issue new POST request. 

Oleg

On Fri, 2003-03-07 at 19:58, David Kavanagh wrote:
> Thomas,
> I'd like to hear more about this because I don't understand how the 
> browser can do that. I know if the form requires POST, the browser 
> simply can't issue GET and expect it to work. Hmm, are you saying that 
> the browser just looks in the response header and issues a GET to follow 
> the redirect? OK, I would expect something along those lines
> 
> David
> 
> [EMAIL PROTECTED] wrote:
> 
> >I am with you Oleg! Some times ago I had the same "problem" but it figured
> >out that the browsers follow the redirects not within the PostMethod but
> >they instead execute a GetMethod. If they wouldn't do so the client could
> >have an wrong url "displayed".
> >
> >Gtx,
> >Thomas
> >
> >-Ursprüngliche Nachricht-
> >Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
> >Gesendet: Freitag, 7. März 2003 17:39
> >An: Commons HttpClient Project
> >Betreff: RE: post redirect
> >
> >
> >David
> >
> >HttpClient is a library, whereas a browser is a totally different kind of
> >beast.
> >
> >RFC 2616 says the following:
> >
> >"...
> >   If the 301 status code is received in response to a request other
> >   than GET or HEAD, the user agent MUST NOT automatically redirect the
> >   request unless it can be confirmed by the user, since this might
> >   change the conditions under which the request was issued
> >..."
> >
> >A well-behaving browser should provide the end user with a confirmation
> >dialog or a configuration option to automatically perform POST redirects.
> >HttpClient can't have that luxury, as it is not supposed to be directly
> >interacting with the end user. I am personally convinced that POST redirect
> >should be handled by the application that consumes Httpclient's services.
> >All it basically takes is a retry loop
> >
> >Does anyone see that differently?
> >
> >Cheers
> >
> >Oleg
> >
> >
> >-Original Message-
> >From: David Kavanagh [mailto:[EMAIL PROTECTED]
> >Sent: Freitag, 7. März 2003 17:24
> >To: [EMAIL PROTECTED]
> >Subject: post redirect
> >
> >
> >I've been working with httpclient for a couple of days to build a Cocoon 
> >transformer that helps me build pipelines to navigate web sites and 
> >extract data. I've read the parts of RFC2616 that deal with redirects 
> >and state they are automatic on the client only for GET and HEAD 
> >methods. I know the JDC and a web site I wrote use POST for the login 
> >form and issue a redirect as a response. Any browser I've tried this 
> >with honors the redirect. I can send some test code I've been using to 
> >test the automated login (that includes handling cookies).
> >Anyway, I've observed browsers honoring the redirect on a POST, can't 
> >httpclient be configured that way? Looking at the source code tells me 
> >no. (I've been using 2.0 alpha 3).
> >
> >Thanks,
> >David
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >  
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: post redirect

[David Kavanagh]

Thomas,
I'd like to hear more about this because I don't understand how the 
browser can do that. I know if the form requires POST, the browser 
simply can't issue GET and expect it to work. Hmm, are you saying that 
the browser just looks in the response header and issues a GET to follow 
the redirect? OK, I would expect something along those lines

David

[EMAIL PROTECTED] wrote:

I am with you Oleg! Some times ago I had the same "problem" but it figured
out that the browsers follow the redirects not within the PostMethod but
they instead execute a GetMethod. If they wouldn't do so the client could
have an wrong url "displayed".
Gtx,
Thomas
-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 17:39
An: Commons HttpClient Project
Betreff: RE: post redirect
David

HttpClient is a library, whereas a browser is a totally different kind of
beast.
RFC 2616 says the following:

"...
  If the 301 status code is received in response to a request other
  than GET or HEAD, the user agent MUST NOT automatically redirect the
  request unless it can be confirmed by the user, since this might
  change the conditions under which the request was issued
..."
A well-behaving browser should provide the end user with a confirmation
dialog or a configuration option to automatically perform POST redirects.
HttpClient can't have that luxury, as it is not supposed to be directly
interacting with the end user. I am personally convinced that POST redirect
should be handled by the application that consumes Httpclient's services.
All it basically takes is a retry loop
Does anyone see that differently?

Cheers

Oleg

-Original Message-
From: David Kavanagh [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 17:24
To: [EMAIL PROTECTED]
Subject: post redirect
I've been working with httpclient for a couple of days to build a Cocoon 
transformer that helps me build pipelines to navigate web sites and 
extract data. I've read the parts of RFC2616 that deal with redirects 
and state they are automatic on the client only for GET and HEAD 
methods. I know the JDC and a web site I wrote use POST for the login 
form and issue a redirect as a response. Any browser I've tried this 
with honors the redirect. I can send some test code I've been using to 
test the automated login (that includes handling cookies).
Anyway, I've observed browsers honoring the redirect on a POST, can't 
httpclient be configured that way? Looking at the source code tells me 
no. (I've been using 2.0 alpha 3).

Thanks,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17432] - '100-continue' response times out unexpectedly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17432

'100-continue' response times out unexpectedly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17768] - Cookies with null value are not formatted correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17768

Cookies with null value are not formatted correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Empty cookie problem

[Oleg Kalnichevski]

Tom,
The fix has been applied
Many thanks for having reported this bug 
Cheers
Oleg

On Fri, 2003-03-07 at 00:10, Tom Samplonius wrote:
>   I have a server that sets a bunch of empty cookies:
> 
> 2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=; 
> path=/[\r][\n]"
> 2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=; 
> path=/[\r][\n]"
> 
> 
>   On subsequent requests, httpclient attaches these cookies thusly:
> 
> 2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; 
> list%2ESince=null; $Path=/[\r][\n]"
> 2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; 
> search%2EPhoneSDA=null; $Path=/[\r][\n]"
> 
> 
>   I'm not sure how to read this portion of wirelog, but seems that actual
> values containing the string "null" are being sent as part of the request.
> In the response to my request, the server now echos cookies with "null"
> values back to me.
> 
> 
> 2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=null; 
> path=/[\r][\n]"
> 2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=null; 
> path=/[\r][\n]"
> 
> 
>   This isn't good.  Basically, the list.Since= cookie is being
> converted to list.Since=null.  This causes the server's script to
> crash:
> 
> Microsoft VBScript runtime  error 
> '800a000d'
> 
> Type mismatch: 'CINT'
> 
> /listCust.asp, line 
> 283 
> 
> 
>   I guess the script tries to assign the string "null" to an integer, and
> dies.
> 
> 
> 
> Tom
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12798] - Path should not be encoded in HttpMethodBase

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12798

Path should not be encoded in HttpMethodBase





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 17:49 ---
Currently HttpMethodBase#generateRequestLine() is a bloody mess. Any reasonable 
solution to this problem should be preceded by method re-write. Here's my shot 
at it

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12798] - Path should not be encoded in HttpMethodBase

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12798

Path should not be encoded in HttpMethodBase





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 17:47 ---
Created an attachment (id=5213)
HttpMethodBase#generateRequestLine() refactored

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: post redirect

[Kalnichevski, Oleg]

David

We have no intention of becoming RFC Ayatollahs here. Really. We have planned a 
complete revamp of redirect logic right after 2.0 release. I see no problem in giving 
an option of automatically redirecting POST requests, which would be disabled by 
default, so the HttpClient consumer would have to explicitly enable it.

Feel free to file a bug (feature request) report meanwhile. The request would still 
have to be approved by other HttpClient developers

http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Commons

Cheers

Oleg

-Original Message-
From: David Kavanagh [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 17:45
To: Commons HttpClient Project
Subject: Re: post redirect


Thanks,
While I see your point, I also didn't see any nice way to do this 
without yanking a bunch of code out of HttpMethodBase.java and pasting 
it into my application. I'd really like the option of overriding the 
default behaviour to keep my code simpler. Make sense?
I've developing enough years to have seen the tradeoffs between making 
it "perfect" and making it work. I know you are trying to be true to the 
RFC, but I've found that with the web, there are always exceptions!

Regards,
David

Kalnichevski, Oleg wrote:

>David
>
>HttpClient is a library, whereas a browser is a totally different kind of beast.
>
>RFC 2616 says the following:
>
>"...
>   If the 301 status code is received in response to a request other
>   than GET or HEAD, the user agent MUST NOT automatically redirect the
>   request unless it can be confirmed by the user, since this might
>   change the conditions under which the request was issued
>..."
>
>A well-behaving browser should provide the end user with a confirmation dialog or a 
>configuration option to automatically perform POST redirects. HttpClient can't have 
>that luxury, as it is not supposed to be directly interacting with the end user. I am 
>personally convinced that POST redirect should be handled by the application that 
>consumes Httpclient's services. All it basically takes is a retry loop
>
>Does anyone see that differently?
>
>Cheers
>
>Oleg
>
>
>-Original Message-
>From: David Kavanagh [mailto:[EMAIL PROTECTED]
>Sent: Freitag, 7. März 2003 17:24
>To: [EMAIL PROTECTED]
>Subject: post redirect
>
>
>I've been working with httpclient for a couple of days to build a Cocoon 
>transformer that helps me build pipelines to navigate web sites and 
>extract data. I've read the parts of RFC2616 that deal with redirects 
>and state they are automatic on the client only for GET and HEAD 
>methods. I know the JDC and a web site I wrote use POST for the login 
>form and issue a redirect as a response. Any browser I've tried this 
>with honors the redirect. I can send some test code I've been using to 
>test the automated login (that includes handling cookies).
>Anyway, I've observed browsers honoring the redirect on a POST, can't 
>httpclient be configured that way? Looking at the source code tells me 
>no. (I've been using 2.0 alpha 3).
>
>Thanks,
>David
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>  
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: post redirect

[mathis]

I am with you Oleg! Some times ago I had the same "problem" but it figured
out that the browsers follow the redirects not within the PostMethod but
they instead execute a GetMethod. If they wouldn't do so the client could
have an wrong url "displayed".

Gtx,
Thomas

-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 17:39
An: Commons HttpClient Project
Betreff: RE: post redirect


David

HttpClient is a library, whereas a browser is a totally different kind of
beast.

RFC 2616 says the following:

"...
   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued
..."

A well-behaving browser should provide the end user with a confirmation
dialog or a configuration option to automatically perform POST redirects.
HttpClient can't have that luxury, as it is not supposed to be directly
interacting with the end user. I am personally convinced that POST redirect
should be handled by the application that consumes Httpclient's services.
All it basically takes is a retry loop

Does anyone see that differently?

Cheers

Oleg


-Original Message-
From: David Kavanagh [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 17:24
To: [EMAIL PROTECTED]
Subject: post redirect


I've been working with httpclient for a couple of days to build a Cocoon 
transformer that helps me build pipelines to navigate web sites and 
extract data. I've read the parts of RFC2616 that deal with redirects 
and state they are automatic on the client only for GET and HEAD 
methods. I know the JDC and a web site I wrote use POST for the login 
form and issue a redirect as a response. Any browser I've tried this 
with honors the redirect. I can send some test code I've been using to 
test the automated login (that includes handling cookies).
Anyway, I've observed browsers honoring the redirect on a POST, can't 
httpclient be configured that way? Looking at the source code tells me 
no. (I've been using 2.0 alpha 3).

Thanks,
David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: post redirect

[David Kavanagh]

Thanks,
While I see your point, I also didn't see any nice way to do this 
without yanking a bunch of code out of HttpMethodBase.java and pasting 
it into my application. I'd really like the option of overriding the 
default behaviour to keep my code simpler. Make sense?
I've developing enough years to have seen the tradeoffs between making 
it "perfect" and making it work. I know you are trying to be true to the 
RFC, but I've found that with the web, there are always exceptions!

Regards,
David
Kalnichevski, Oleg wrote:

David

HttpClient is a library, whereas a browser is a totally different kind of beast.

RFC 2616 says the following:

"...
  If the 301 status code is received in response to a request other
  than GET or HEAD, the user agent MUST NOT automatically redirect the
  request unless it can be confirmed by the user, since this might
  change the conditions under which the request was issued
..."
A well-behaving browser should provide the end user with a confirmation dialog or a configuration option to automatically perform POST redirects. HttpClient can't have that luxury, as it is not supposed to be directly interacting with the end user. I am personally convinced that POST redirect should be handled by the application that consumes Httpclient's services. All it basically takes is a retry loop

Does anyone see that differently?

Cheers

Oleg

-Original Message-
From: David Kavanagh [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 17:24
To: [EMAIL PROTECTED]
Subject: post redirect
I've been working with httpclient for a couple of days to build a Cocoon 
transformer that helps me build pipelines to navigate web sites and 
extract data. I've read the parts of RFC2616 that deal with redirects 
and state they are automatic on the client only for GET and HEAD 
methods. I know the JDC and a web site I wrote use POST for the login 
form and issue a redirect as a response. Any browser I've tried this 
with honors the redirect. I can send some test code I've been using to 
test the automated login (that includes handling cookies).
Anyway, I've observed browsers honoring the redirect on a POST, can't 
httpclient be configured that way? Looking at the source code tells me 
no. (I've been using 2.0 alpha 3).

Thanks,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: post redirect

[Kalnichevski, Oleg]

David

HttpClient is a library, whereas a browser is a totally different kind of beast.

RFC 2616 says the following:

"...
   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued
..."

A well-behaving browser should provide the end user with a confirmation dialog or a 
configuration option to automatically perform POST redirects. HttpClient can't have 
that luxury, as it is not supposed to be directly interacting with the end user. I am 
personally convinced that POST redirect should be handled by the application that 
consumes Httpclient's services. All it basically takes is a retry loop

Does anyone see that differently?

Cheers

Oleg


-Original Message-
From: David Kavanagh [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 17:24
To: [EMAIL PROTECTED]
Subject: post redirect


I've been working with httpclient for a couple of days to build a Cocoon 
transformer that helps me build pipelines to navigate web sites and 
extract data. I've read the parts of RFC2616 that deal with redirects 
and state they are automatic on the client only for GET and HEAD 
methods. I know the JDC and a web site I wrote use POST for the login 
form and issue a redirect as a response. Any browser I've tried this 
with honors the redirect. I can send some test code I've been using to 
test the automated login (that includes handling cookies).
Anyway, I've observed browsers honoring the redirect on a POST, can't 
httpclient be configured that way? Looking at the source code tells me 
no. (I've been using 2.0 alpha 3).

Thanks,
David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

post redirect

[David Kavanagh]

I've been working with httpclient for a couple of days to build a Cocoon 
transformer that helps me build pipelines to navigate web sites and 
extract data. I've read the parts of RFC2616 that deal with redirects 
and state they are automatic on the client only for GET and HEAD 
methods. I know the JDC and a web site I wrote use POST for the login 
form and issue a redirect as a response. Any browser I've tried this 
with honors the redirect. I can send some test code I've been using to 
test the automated login (that includes handling cookies).
Anyway, I've observed browsers honoring the redirect on a POST, can't 
httpclient be configured that way? Looking at the source code tells me 
no. (I've been using 2.0 alpha 3).

Thanks,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] HttpClient was rejecting some cookies a browser wouldaccept

[Padraig O'hIceadha]

Hi Oleg,

   That would be really excellent.

   Thanks a lot,

 Padraig

Kalnichevski, Oleg wrote:

Hi Padraig 

Makes sense to me. If no one loudly objects, I'll apply the patch by Monday the latest (or shall I say monday? ;-))

Cheers

Oleg

-Original Message-
From: Padraig O'hIceadha [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 16:00
To: [EMAIL PROTECTED]
Subject: [PATCH] HttpClient was rejecting some cookies a browser would
accept
Hi,

   I found that cookies generated by WebLogic were being rejected by 
HttpClient as it didn't like the format of the Expires field.

   From reading the specs I think that HttpClient is not at fault, in 
that WebLogic does not seem to be using a 100% correct date format.

   However their error is minor (it uses incorrect case for the
day and month names) and I think it would be useful if HttpClient
were forgiving in this regard.
   For example, WebLogic sends
expires=thursday, 06-mar-2003 04:44:00 GMT
   where it should send
expires=Thursday, 06-Mar-2003 04:44:00 GMT
This causes a problem in the parse method in HeaderElement
where it has extra code for recognising when a , in the cookie
string is part of a date.
To check this it does a case sensitive match against all the
valid combinations ("Monday", "Tuesday" etc). As the match is
case sensitive it doesn't recognise the weblogic expires as a
date and the expires field ends up simply as "thursday", which
later fails parsing by SimpleDateFormat.
The patch below changes this to use a case insensitive
comparison.
Regards,

  Padraig

Index: HeaderElement.java
===
RCS file: 
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HeaderElement.java,v
retrieving revision 1.16
diff -u -r1.16 HeaderElement.java
--- HeaderElement.java  31 Jan 2003 00:33:36 -  1.16
+++ HeaderElement.java  7 Mar 2003 14:41:07 -
@@ -300,22 +300,24 @@
  * the expires date format is "Wdy, DD-Mon-YY HH:MM:SS 
GMT".
  * Notice that there is always comma(',') sign.
  * For the general cases, rfc1123-date, rfc850-date.
+* NB some servers send the day & month names in the 
wrong case
  */
 if (tokenizer.hasMoreTokens()) {
-if (nextToken.endsWith("Mon")
-|| nextToken.endsWith("Tue")
-|| nextToken.endsWith("Wed")
-|| nextToken.endsWith("Thu")
-|| nextToken.endsWith("Fri")
-|| nextToken.endsWith("Sat")
-|| nextToken.endsWith("Sun")
-|| nextToken.endsWith("Monday")
-|| nextToken.endsWith("Tuesday")
-|| nextToken.endsWith("Wednesday")
-|| nextToken.endsWith("Thursday")
-|| nextToken.endsWith("Friday")
-|| nextToken.endsWith("Saturday")
-|| nextToken.endsWith("Sunday")) {
+   String possibleExpiresField = nextToken.toLowerCase();
+if (possibleExpiresField.endsWith("mon")
+|| possibleExpiresField.endsWith("tue")
+|| possibleExpiresField.endsWith("wed")
+|| possibleExpiresField.endsWith("thu")
+|| possibleExpiresField.endsWith("fri")
+|| possibleExpiresField.endsWith("sat")
+|| possibleExpiresField.endsWith("sun")
+|| possibleExpiresField.endsWith("monday")
+|| possibleExpiresField.endsWith("tuesday")
+|| possibleExpiresField.endsWith("wednesday")
+|| possibleExpiresField.endsWith("thursday")
+|| possibleExpiresField.endsWith("friday")
+|| possibleExpiresField.endsWith("saturday")
+|| possibleExpiresField.endsWith("sunday")) {

 nextToken += "," + tokenizer.nextToken();
 }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH] HttpClient was rejecting some cookies a browser would accept

[Kalnichevski, Oleg]

Hi Padraig 

Makes sense to me. If no one loudly objects, I'll apply the patch by Monday the latest 
(or shall I say monday? ;-))

Cheers

Oleg

-Original Message-
From: Padraig O'hIceadha [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 16:00
To: [EMAIL PROTECTED]
Subject: [PATCH] HttpClient was rejecting some cookies a browser would
accept


Hi,

I found that cookies generated by WebLogic were being rejected by 
HttpClient as it didn't like the format of the Expires field.

From reading the specs I think that HttpClient is not at fault, in 
that WebLogic does not seem to be using a 100% correct date format.

However their error is minor (it uses incorrect case for the
day and month names) and I think it would be useful if HttpClient
were forgiving in this regard.

For example, WebLogic sends
expires=thursday, 06-mar-2003 04:44:00 GMT
where it should send
expires=Thursday, 06-Mar-2003 04:44:00 GMT

 This causes a problem in the parse method in HeaderElement
where it has extra code for recognising when a , in the cookie
string is part of a date.

 To check this it does a case sensitive match against all the
valid combinations ("Monday", "Tuesday" etc). As the match is
case sensitive it doesn't recognise the weblogic expires as a
date and the expires field ends up simply as "thursday", which
later fails parsing by SimpleDateFormat.

 The patch below changes this to use a case insensitive
comparison.

 Regards,

   Padraig

Index: HeaderElement.java
===
RCS file: 
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HeaderElement.java,v
retrieving revision 1.16
diff -u -r1.16 HeaderElement.java
--- HeaderElement.java  31 Jan 2003 00:33:36 -  1.16
+++ HeaderElement.java  7 Mar 2003 14:41:07 -
@@ -300,22 +300,24 @@
   * the expires date format is "Wdy, DD-Mon-YY HH:MM:SS 
GMT".
   * Notice that there is always comma(',') sign.
   * For the general cases, rfc1123-date, rfc850-date.
+* NB some servers send the day & month names in the 
wrong case
   */
  if (tokenizer.hasMoreTokens()) {
-if (nextToken.endsWith("Mon")
-|| nextToken.endsWith("Tue")
-|| nextToken.endsWith("Wed")
-|| nextToken.endsWith("Thu")
-|| nextToken.endsWith("Fri")
-|| nextToken.endsWith("Sat")
-|| nextToken.endsWith("Sun")
-|| nextToken.endsWith("Monday")
-|| nextToken.endsWith("Tuesday")
-|| nextToken.endsWith("Wednesday")
-|| nextToken.endsWith("Thursday")
-|| nextToken.endsWith("Friday")
-|| nextToken.endsWith("Saturday")
-|| nextToken.endsWith("Sunday")) {
+   String possibleExpiresField = nextToken.toLowerCase();
+if (possibleExpiresField.endsWith("mon")
+|| possibleExpiresField.endsWith("tue")
+|| possibleExpiresField.endsWith("wed")
+|| possibleExpiresField.endsWith("thu")
+|| possibleExpiresField.endsWith("fri")
+|| possibleExpiresField.endsWith("sat")
+|| possibleExpiresField.endsWith("sun")
+|| possibleExpiresField.endsWith("monday")
+|| possibleExpiresField.endsWith("tuesday")
+|| possibleExpiresField.endsWith("wednesday")
+|| possibleExpiresField.endsWith("thursday")
+|| possibleExpiresField.endsWith("friday")
+|| possibleExpiresField.endsWith("saturday")
+|| possibleExpiresField.endsWith("sunday")) {

  nextToken += "," + tokenizer.nextToken();
  }


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] HttpClient was rejecting some cookies a browser would accept

[Padraig O'hIceadha]

Hi,

   I found that cookies generated by WebLogic were being rejected by 
HttpClient as it didn't like the format of the Expires field.

   From reading the specs I think that HttpClient is not at fault, in 
that WebLogic does not seem to be using a 100% correct date format.

   However their error is minor (it uses incorrect case for the
day and month names) and I think it would be useful if HttpClient
were forgiving in this regard.
   For example, WebLogic sends
expires=thursday, 06-mar-2003 04:44:00 GMT
   where it should send
expires=Thursday, 06-Mar-2003 04:44:00 GMT
This causes a problem in the parse method in HeaderElement
where it has extra code for recognising when a , in the cookie
string is part of a date.
To check this it does a case sensitive match against all the
valid combinations ("Monday", "Tuesday" etc). As the match is
case sensitive it doesn't recognise the weblogic expires as a
date and the expires field ends up simply as "thursday", which
later fails parsing by SimpleDateFormat.
The patch below changes this to use a case insensitive
comparison.
Regards,

  Padraig

Index: HeaderElement.java
===
RCS file: 
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HeaderElement.java,v
retrieving revision 1.16
diff -u -r1.16 HeaderElement.java
--- HeaderElement.java  31 Jan 2003 00:33:36 -  1.16
+++ HeaderElement.java  7 Mar 2003 14:41:07 -
@@ -300,22 +300,24 @@
  * the expires date format is "Wdy, DD-Mon-YY HH:MM:SS 
GMT".
  * Notice that there is always comma(',') sign.
  * For the general cases, rfc1123-date, rfc850-date.
+* NB some servers send the day & month names in the 
wrong case
  */
 if (tokenizer.hasMoreTokens()) {
-if (nextToken.endsWith("Mon")
-|| nextToken.endsWith("Tue")
-|| nextToken.endsWith("Wed")
-|| nextToken.endsWith("Thu")
-|| nextToken.endsWith("Fri")
-|| nextToken.endsWith("Sat")
-|| nextToken.endsWith("Sun")
-|| nextToken.endsWith("Monday")
-|| nextToken.endsWith("Tuesday")
-|| nextToken.endsWith("Wednesday")
-|| nextToken.endsWith("Thursday")
-|| nextToken.endsWith("Friday")
-|| nextToken.endsWith("Saturday")
-|| nextToken.endsWith("Sunday")) {
+   String possibleExpiresField = nextToken.toLowerCase();
+if (possibleExpiresField.endsWith("mon")
+|| possibleExpiresField.endsWith("tue")
+|| possibleExpiresField.endsWith("wed")
+|| possibleExpiresField.endsWith("thu")
+|| possibleExpiresField.endsWith("fri")
+|| possibleExpiresField.endsWith("sat")
+|| possibleExpiresField.endsWith("sun")
+|| possibleExpiresField.endsWith("monday")
+|| possibleExpiresField.endsWith("tuesday")
+|| possibleExpiresField.endsWith("wednesday")
+|| possibleExpiresField.endsWith("thursday")
+|| possibleExpiresField.endsWith("friday")
+|| possibleExpiresField.endsWith("saturday")
+|| possibleExpiresField.endsWith("sunday")) {

 nextToken += "," + tokenizer.nextToken();
 }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Can anyone shed some light upon the status of this bug?

[Kalnichevski, Oleg]

Can anyone shed some light upon the status of this bug? It's been marked as critical, 
yet I see no one rushing to fix it. The problems seem to be better addressed by 
Sung-Gu due to his speciality in URI & encoding related stuff but since he has not 
been showing up much recently, someone needs to step in.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12798

Cheers

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 17768] - Cookies with null value are not formatted correctly

[Michael Becke]

Looks good to me.

Mike

On Friday, March 7, 2003, at 08:43 AM, [EMAIL PROTECTED] wrote:

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17768

Cookies with null value are not formatted correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 13:43 
---
Created an attachment (id=5205)
Fix

-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17563] - SSL Tunneling does not work with MultiThreadedHttpConnectionManager

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17563

SSL Tunneling does not work with MultiThreadedHttpConnectionManager

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17768] - Cookies with null value are not formatted correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17768

Cookies with null value are not formatted correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-03-07 13:43 ---
Created an attachment (id=5205)
Fix

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17768] - Cookies with null value are not formatted correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17768

Cookies with null value are not formatted correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Priority|Other   |Medium
   Target Milestone|--- |2.0 Beta 1
Version|1.0 Alpha   |2.0 Alpha 3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17768] New: - Cookies with null value are not formatted correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17768

Cookies with null value are not formatted correctly

   Summary: Cookies with null value are not formatted correctly
   Product: Commons
   Version: 1.0 Alpha
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a server that sets a bunch of empty cookies:

2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=; 
path=/[\r][\n]"
2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=; 
path=/[\r][\n]"


  On subsequent requests, httpclient attaches these cookies thusly:

2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; list%
2ESince=null; $Path=/[\r][\n]"
2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; search%
2EPhoneSDA=null; $Path=/[\r][\n]"


  I'm not sure how to read this portion of wirelog, but seems that actual
values containing the string "null" are being sent as part of the request.
In the response to my request, the server now echos cookies with "null"
values back to me.


2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: search%
2EPhoneSDA=null; path=/[\r][\n]"
2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=null; 
path=/[\r][\n]"


  This isn't good.  Basically, the list.Since= cookie is being
converted to list.Since=null.  This causes the server's script to
crash:

Microsoft VBScript runtime  error '800a000d'

Type mismatch: 'CINT'

/listCust.asp, line 
283 


  I guess the script tries to assign the string "null" to an integer, and
dies.

Reported by Tom Samplonius <[EMAIL PROTECTED]>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] Empty cookie problem

[Kalnichevski, Oleg]

The below attached patch fixes the problem

Cheers

Oleg

-Original Message-
From: Tom Samplonius [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 00:11
To: Commons HttpClient Project
Subject: Empty cookie problem



  I have a server that sets a bunch of empty cookies:

2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=; 
path=/[\r][\n]"
2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=; 
path=/[\r][\n]"


  On subsequent requests, httpclient attaches these cookies thusly:

2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; list%2ESince=null; 
$Path=/[\r][\n]"
2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; 
search%2EPhoneSDA=null; $Path=/[\r][\n]"


  I'm not sure how to read this portion of wirelog, but seems that actual
values containing the string "null" are being sent as part of the request.
In the response to my request, the server now echos cookies with "null"
values back to me.


2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=null; 
path=/[\r][\n]"
2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=null; 
path=/[\r][\n]"


  This isn't good.  Basically, the list.Since= cookie is being
converted to list.Since=null.  This causes the server's script to
crash:

Microsoft VBScript runtime  error '800a000d'

Type mismatch: 'CINT'

/listCust.asp, line 
283 


  I guess the script tries to assign the string "null" to an integer, and
dies.



Tom


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character Encodings

[Adrian Sutton]

Oleg,
Thanks for your responses, I'm confident that I'll be writing the right
information now. :)

> Kalnichevski, Oleg wrote:
> >> 6. Some document types specify the charset inside the document
> >> itself, you should consult the appropriate standards to determine
> >> whether to use the charset specified in the HTTP response or the
> >> charset in the document.
>
> Can you give examples of such document formats?

HTML and XML are examples of this.  In the case of XML (perhaps just for
WebDAV, not sure) the HTTP header should override what the document
specifies.  I'm under the impression that for HTML, the encoding specified
in the document is used first but that may be either wrong or just by
convention rather than by standard.

> > HttpClient is not supposed to be aware of any body content specific
> > stuff. It is HttpClient consumer's responsibility to ensure that the
> > content is properly decoded
>
> This is generally true. HttpClient should only provide means to make
> this step as easy as possible.

Agreed, and with the new (or at least new to me) getContentCharSet,
getResponseCharSet and getRequestCharSet methods, that's all HttpClient
should be expected to do.  I simply plan to add a note in the docs that the
charset specified by the server may not match the charset specified in the
document and you need to have a policy for dealing with that.

For the record, the user guide I'm working on has the following structure:

Authentication Guide (done)
Character Encodings
Cross Host Redirects (done)
Logging Guide (kindly completed by Jeff Dever)
Methods Reference
Options (done)
Get
Head
Post
Multipart Post
Put
Delete
Trace
Sample Code (done - just a link to the sample code directory in CVS, later
it might be worth adding a page describing each of the examples)
Trouble Shooting (done)
Tutorial (done - simple walkthrough that shows the basic approach to using
HttpClient and winds up building a tiny app that GET's a web page)


I've also consolidated the developer documentation a big into the beginnings
of a developer guide which includes links off to the various pages on
contributing to Apache projects and then Jeff's Release Guide and Oleg's
WebApp Test HowTo.

Then I guess it's just a matter of monitoring the mailing lists for frequent
questions and documenting them in a FAQ or adding an article to the user
guide.

I'll probably upload another bundle to the bugzilla bug later tonight for
people to take a look at and provide feedback on, but any feedback on the
structure is welcome.

Adrian Sutton.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Copy or clone a HttpMethod

[mathis]

At first I'll try to use org.apache.commons.beanutils.BeanUtils.cloneBean().
If this method does not meet my requirements I'll write a utility class.

Thomas

-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 11:52
An: Commons HttpClient Project
Betreff: RE: Copy or clone a HttpMethod 


I see. Unfortunately I personally can't think of an elegant way to clone
HTTP methods. If you decide to write HTTP method cloning routine, would you
mind contributing it as a utility class for HttpClient's yet to be founded
contribution package?

Oleg

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 11:45
To: [EMAIL PROTECTED]
Subject: AW: Copy or clone a HttpMethod 


I want to use a method twice with all headers, paths, ... set. recycle()
would delete all these settings.
As I can not execute a method twice I want to clone/copy it before I execute
it.

Thomas

-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 11:34
An: Commons HttpClient Project
Betreff: RE: Copy or clone a HttpMethod 


Hi Thomas

Some clarifications needed: do you need an exact copy of an Http method or
you just want to be able to reuse the same object twice? 

The problem is that (in my opinion) HttpMethod should be split into
HttpRequest/HttpResponse pair. That would allow HttpRequest objects to be
reused multiple time without having to go into trouble of 'recycling'
objects. However, such a radical design change will not happen any time soon
(if approved at all)

Oleg

-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Copy or clone a HttpMethod

[Kalnichevski, Oleg]

I see. Unfortunately I personally can't think of an elegant way to clone HTTP methods. 
If you decide to write HTTP method cloning routine, would you mind contributing it as 
a utility class for HttpClient's yet to be founded contribution package?

Oleg

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 11:45
To: [EMAIL PROTECTED]
Subject: AW: Copy or clone a HttpMethod 


I want to use a method twice with all headers, paths, ... set. recycle()
would delete all these settings.
As I can not execute a method twice I want to clone/copy it before I execute
it.

Thomas

-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 11:34
An: Commons HttpClient Project
Betreff: RE: Copy or clone a HttpMethod 


Hi Thomas

Some clarifications needed: do you need an exact copy of an Http method or
you just want to be able to reuse the same object twice? 

The problem is that (in my opinion) HttpMethod should be split into
HttpRequest/HttpResponse pair. That would allow HttpRequest objects to be
reused multiple time without having to go into trouble of 'recycling'
objects. However, such a radical design change will not happen any time soon
(if approved at all)

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Copy or clone a HttpMethod

[mathis]

I want to use a method twice with all headers, paths, ... set. recycle()
would delete all these settings.
As I can not execute a method twice I want to clone/copy it before I execute
it.

Thomas

-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 7. März 2003 11:34
An: Commons HttpClient Project
Betreff: RE: Copy or clone a HttpMethod 


Hi Thomas

Some clarifications needed: do you need an exact copy of an Http method or
you just want to be able to reuse the same object twice? 

The problem is that (in my opinion) HttpMethod should be split into
HttpRequest/HttpResponse pair. That would allow HttpRequest objects to be
reused multiple time without having to go into trouble of 'recycling'
objects. However, such a radical design change will not happen any time soon
(if approved at all)

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character Encodings

[Ortwin Glück]

Kalnichevski, Oleg wrote:
6. Some document types specify the charset inside the document
itself, you should consult the appropriate standards to determine
whether to use the charset specified in the HTTP response or the
charset in the document.
Can you give examples of such document formats?

HttpClient is not supposed to be aware of any body content specific
stuff. It is HttpClient consumer's responsibility to ensure that the
content is properly decoded
This is generally true. HttpClient should only provide means to make 
this step as easy as possible.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Copy or clone a HttpMethod

[Kalnichevski, Oleg]

Hi Thomas

Some clarifications needed: do you need an exact copy of an Http method or you just 
want to be able to reuse the same object twice? 

The problem is that (in my opinion) HttpMethod should be split into 
HttpRequest/HttpResponse pair. That would allow HttpRequest objects to be reused 
multiple time without having to go into trouble of 'recycling' objects. However, such 
a radical design change will not happen any time soon (if approved at all)

Oleg

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 10:41
To: [EMAIL PROTECTED]
Subject: Copy or clone a HttpMethod 


Hello!

I don't find the public clone method in HttpMethod. I want to copy (or
clone) a HttpMethod before I execute it (or can I execute a method twice? I
think it's not possible.). Is there a simple way to do that or would that be
an enhancement?

Thx, Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Character Encodings

[Kalnichevski, Oleg]

Hi Adrian

> 1. URLs should only consist of ISO-8859-1 characters whenever possible as
> this is the encoding used by RFC 1738 and using other encodings may cause
> compatibility issues with some servers (eg: Windows Web Folders).  This is
> mostly due to the fact that there is no way to determine the encoding used
> for the URL.

I believe it is correct. However, you may need to consult with Sung-Gu on this matter

> 2. The headers of a HTTP request/response must always be ISO 8859-1 (or is
> this ASCII?) as per the HTTP standard.

Header elements (status line + headers) must be in US-ASCII according to the HTTP spec


> 3. The Content-Type: header may specify a charset for the body of the HTTP
> request/response, eg: Content-Type: text/html; charset=UTF-8

Correct

> 4. Is there any simple way to extract the charset returned by the server
> from HttpClient?  If not we probably should add one.  Obviously you could
> get the Content-Type header and parse it but since HttpClient already does
> this (I think) it would be better to avoid it.

HttpMethodBase#getResponseCharSet()
HttpMethodBase#getRequestCharSet()

> 5. getResponseBodyAsString always uses the platform default encoding.  Why
> doesn't this use the charset specified in the HTTP request?

HttpMethodBase#getResponseBodyAsString() does use the charset specified in the 
response 'Content-Type' header (when available)

> 6. Some document types specify the charset inside the document itself, you
> should consult the appropriate standards to determine whether to use the
> charset specified in the HTTP response or the charset in the document.

HttpClient is not supposed to be aware of any body content specific stuff. It is 
HttpClient consumer's responsibility to ensure that the content is properly decoded

Cheers

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with MultipartPostMethod via HTTPS

[TANAKA Yuui]

Oleg

Thank you for your advice. Some modules offered by a software vendor
depends on Tomcat 3.2.x, so I'm compelled to use. I tried FileUpload on
Tomcat 4.1.18 with SSL and it worked fine! I'll try with Apache + Tomcat
3.2.4 later. It seems that the factor of the problem is at server side.

Thanks,
Yuui


> Yuui
> 
> Tomcat 3.2.4 is fairly out-dated. Seriously consider upgrading. I believe ancient 
> Tomcat may be causing the problem in the first place. Try examining Tomcat's logs 
> for error messages or any other clues. Another idea is to run your code using plain 
> HTTP and see if that makes any difference.
> 
> Cheers
> 
> Oleg

--
Marineroad Inc. / TANAKA Yuui <[EMAIL PROTECTED]>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Character Encodings

[Adrian Sutton]

Hi all,
I'm not too certain about all the details of character encodings in
HttpClient but it is on my list of docs to write so would like to confirm a
few things and extract any thoughts about it.

1. URLs should only consist of ISO-8859-1 characters whenever possible as
this is the encoding used by RFC 1738 and using other encodings may cause
compatibility issues with some servers (eg: Windows Web Folders).  This is
mostly due to the fact that there is no way to determine the encoding used
for the URL.

2. The headers of a HTTP request/response must always be ISO 8859-1 (or is
this ASCII?) as per the HTTP standard.

3. The Content-Type: header may specify a charset for the body of the HTTP
request/response, eg: Content-Type: text/html; charset=UTF-8

4. Is there any simple way to extract the charset returned by the server
from HttpClient?  If not we probably should add one.  Obviously you could
get the Content-Type header and parse it but since HttpClient already does
this (I think) it would be better to avoid it.

5. getResponseBodyAsString always uses the platform default encoding.  Why
doesn't this use the charset specified in the HTTP request?

6. Some document types specify the charset inside the document itself, you
should consult the appropriate standards to determine whether to use the
charset specified in the HTTP response or the charset in the document.

Any other things that should be documented would be good to know as well.

Thanks in advance.

Adrian "Doc Boy" Sutton.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Copy or clone a HttpMethod

[mathis]

Hello!

I don't find the public clone method in HttpMethod. I want to copy (or
clone) a HttpMethod before I execute it (or can I execute a method twice? I
think it's not possible.). Is there a simple way to do that or would that be
an enhancement?

Thx, Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Problem with MultipartPostMethod via HTTPS

[Kalnichevski, Oleg]

Yuui

Tomcat 3.2.4 is fairly out-dated. Seriously consider upgrading. I believe ancient 
Tomcat may be causing the problem in the first place. Try examining Tomcat's logs for 
error messages or any other clues. Another idea is to run your code using plain HTTP 
and see if that makes any difference.

Cheers

Oleg

-Original Message-
From: TANAKA Yuui [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 09:32
To: Commons HttpClient Project
Subject: Re: Problem with MultipartPostMethod via HTTPS


Thank you for your quick reply.

I tried the latest HttpClient from CVS, but failed. And I did on another
machine, then I got the same result. As you point out the problem may be
occurred in the server side. The processing library for file upload is
Jakarta Commons FileUpload 1.0 and I run it on Tomcat 3.2.4 with SSL.
I'll take a look at them.

Thanks,

Yuui


--
Marineroad Inc. / TANAKA Yuui <[EMAIL PROTECTED]>


> I'm not exactly sure what's going wrong here.  It seems that the  
> connection is being closed/reused on the either the client or server  
> side before the entire response is read.  I tried your code on my  
> machine at home and it worked well.  I am guessing the problem is  
> either with the version of HttpClient you have or the server that's  
> processing the file upload.  Can you try this again with the latest  
> HttpClient code from CVS?
> 
> Thanks,
> 
> Mike


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Empty cookie problem

[Kalnichevski, Oleg]

Tom,
This is clearly a bug. I will be working on a fix shortly. Thanks for tracking it down
Cheers
Oleg

-Original Message-
From: Tom Samplonius [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 00:11
To: Commons HttpClient Project
Subject: Empty cookie problem



  I have a server that sets a bunch of empty cookies:

2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=; 
path=/[\r][\n]"
2003/03/06 16:28:52:055 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=; 
path=/[\r][\n]"


  On subsequent requests, httpclient attaches these cookies thusly:

2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; list%2ESince=null; 
$Path=/[\r][\n]"
2003/03/06 16:28:55:480 PST [DEBUG] wire - ->> "Cookie: $Version=0; 
search%2EPhoneSDA=null; $Path=/[\r][\n]"


  I'm not sure how to read this portion of wirelog, but seems that actual
values containing the string "null" are being sent as part of the request.
In the response to my request, the server now echos cookies with "null"
values back to me.


2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: search%2EPhoneSDA=null; 
path=/[\r][\n]"
2003/03/06 16:28:55:660 PST [DEBUG] wire - -<< "Set-Cookie: list%2ESince=null; 
path=/[\r][\n]"


  This isn't good.  Basically, the list.Since= cookie is being
converted to list.Since=null.  This causes the server's script to
crash:

Microsoft VBScript runtime  error '800a000d'

Type mismatch: 'CINT'

/listCust.asp, line 
283 


  I guess the script tries to assign the string "null" to an integer, and
dies.



Tom


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: patch comments

[Kalnichevski, Oleg]

+1 

I am glad the patch will also eliminate tight coupling between HttpMethodBase & 
ConnectMethod

Cheers

Oleg

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 03:41
To: Commons Project
Subject: patch comments


Are there any comment for or against the following patches?

the patch attached to:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17563

and:

Begin forwarded message:

> From: Michael Becke <[EMAIL PROTECTED]>
> Date: Sat Mar 1, 2003  12:36:02 PM US/Eastern
> To: Commons Project <[EMAIL PROTECTED]>
> Subject: [PATCH] SSL Tunneling Connection Timeout
>
> As discussed in the IRC session on Thursday here is a patch that 
> should "fix" the timeout problem that occurs when using Https through 
> a proxy.  This fixes the problem by not allowing HttpConnections that 
> are tunneled to be reused.  This is by no means a perfect solution but 
> it should add some stability.  There is still a potential problem in 
> HttpMethodBase.processRequest() when a retry occurs.  In this case the 
> connection will be reopen but without the necessary step of creating 
> the proxy tunnel.  One option here would be to set maxRetriesto 0.  
> Please take a look and let me know.
>
> Thanks,
>
> Mike
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: To all those who have been experiencing problems with 'expect:100-continue' stuff

[Ingo Brunberg]

For me it is now working, too.

Good work,
Ingo

> Oleg,
> >The 'expect: 100-continue' related code has been significantly refactored
> 
> I am no longer experiencing the timeout problem (everything works well when
> sending the expect-100 header).
> 
> However, my HTTP server (Jetty) seems to be still sending "HTTP/1.1 100
> Continue" when the Expect header is absent (in the HTTP RFC, this is a
> "SHOULD NOT")
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
> 
> Httpclient shows an INFO level warning about this.
> 
> I'm am following this up with the Jetty community.
> 
> Cheers, Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with MultipartPostMethod via HTTPS

[TANAKA Yuui]

Thank you for your quick reply.

I tried the latest HttpClient from CVS, but failed. And I did on another
machine, then I got the same result. As you point out the problem may be
occurred in the server side. The processing library for file upload is
Jakarta Commons FileUpload 1.0 and I run it on Tomcat 3.2.4 with SSL.
I'll take a look at them.

Thanks,

Yuui


--
Marineroad Inc. / TANAKA Yuui <[EMAIL PROTECTED]>


> I'm not exactly sure what's going wrong here.  It seems that the  
> connection is being closed/reused on the either the client or server  
> side before the entire response is read.  I tried your code on my  
> machine at home and it worked well.  I am guessing the problem is  
> either with the version of HttpClient you have or the server that's  
> processing the file upload.  Can you try this again with the latest  
> HttpClient code from CVS?
> 
> Thanks,
> 
> Mike


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]