RE: refresh header proxy

[Tim Reilly]

Not to beat a dead horse... but I was surprised this is a non-standard
header so for anyone interested here are my "of interest" links. As Odi
mentions Netscape introduced the header (the meta tag is the html equivalent
to the (non-standard) http header.)

Early draft refers to the Refresh header but marks it "TBS"
http://www.w3.org/Protocols/HTTP/1.1/spec.html#Refresh
Later an issue from the working group says the follow: was not in the 1.1
spec, "due to unexplored security implications"

Post from a 2000 w3c list. Good information for anyone implementing the
behavior expected and wanting to know why 3xx doesn't cover what's done in
the Refresh:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0412.html

The Netscape "vision" for the header.
http://wp.netscape.com/assist/net_sites/pushpull.html

JavaBoutique article showing usage.
http://javaboutique.internet.com/tutorials/JSP/part08/page02.html
mentions non-standard header, but that NS and IE support it.


>
>
[trunc]


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

Re: MultipartPostMethod Help!!

[Mark R. Diggory]

You should send this to the HttpClient dev list.

subscribe: [EMAIL PROTECTED]
post: [EMAIL PROTECTED]
It looks as though the name used for the file is currently converted to 
ascii bytes when the disposition header is written:

in o.a.c.h.methods.multipart.FilePart:

/**
 * Write the disposition header to the output stream
 * @param out The output stream
 * @throws IOException If an IO problem occurs
 * @see Part#sendDispositionHeader(OutputStream)
 */
protected void sendDispositionHeader(OutputStream out)
throws IOException {
LOG.trace("enter sendDispositionHeader(OutputStream out)");
super.sendDispositionHeader(out);
String filename = this.source.getFileName();
if (filename != null) {
out.write(FILE_NAME_BYTES);
out.write(QUOTE_BYTES);
out.write(HttpConstants.getAsciiBytes(filename));
out.write(QUOTE_BYTES);
}
}
Is it a requirement that Disposition Header be in ASCII?

-Mark

Stéphane Houle wrote:

Hi everyone,

I'm very sorry to send an email directly to all of you but I saw your 
emails in the MultipartPostMethod source code in HttpClient 2.0 RC2.  
Maybe you can or cannot answer to my question, if not, do you know a 
mailing list or a person how can answer to my question ??

Here's my question:

I'm using MultipartPostMethod to send a file, everything works well but 
when the filename contains French character like "é", the character is 
always converted to ?.  I though it was the encoding that was setted to 
US-ASCII or something like that but no, the encoding is setted to 
ISO-8859-1.  I tried all sort to method to send the file:

- set the File object
- set the File object with the filename
- set a FilePart
- set a FilePart with a FilePartSource
Nothing works, here is a little dump of my Part:

FILE: /home/lhoule/dev/ac-httpClient-1.0/fileTest/toté.mp3
PART 0: ISO-8859-1
PART 0: binary
PART 0: application/octet-stream
PART 0: file
PART 0: 314159265358979323846
I don't know what I can do...  I try to search the web for a solution or 
in jakarta website...  Nothing...  Did you ever have this kind of 
problem??  Or maybe I don't use the MultipartPostMethod correctly to 
support French character??

Any clue?

Thank you very much and sorry again to send an email directly to all of you!

Steph
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25592] - An IOException or RuntimeException leaves the underlying socket in an undetermined state

[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=25592

An IOException or RuntimeException leaves the underlying socket in an undetermined 
state

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 23:09 ---
The patch for the bug #25370 should have taken care of this one too. 

Oleg

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

DO NOT REPLY [Bug 25370] - exception during writeRequest leaves the connection un-released

[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=25370

exception during writeRequest leaves the connection un-released

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 23:04 ---
Patch committed to CVS HEAD. 
Oleg.

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

DO NOT REPLY [Bug 25370] - exception during writeRequest leaves the connection un-released

[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=25370

exception during writeRequest leaves the connection un-released





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 21:07 ---
Looks good.

Mike

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

DO NOT REPLY [Bug 25431] - Cleanup use of EncodingUtil and HttpConstants

[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=25431

Cleanup use of EncodingUtil and HttpConstants





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 20:58 ---
Oleg,

Looks good to me.  The only change I would make is to remove the use of HttpConstants 
in 
HttpConnection.

Mike

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

DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.

[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=26070

[RFE] Allow streaming of POST methods via chunked transfer encoding.





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 19:28 ---
Created an attachment (id=9912)
possible implementation

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

DO NOT REPLY [Bug 26070] New: - [RFE] Allow streaming of POST methods via chunked transfer encoding.

[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=26070

[RFE] Allow streaming of POST methods via chunked transfer encoding.

   Summary: [RFE] Allow streaming of POST methods via chunked
transfer encoding.
   Product: Commons
   Version: 2.0 Beta 2
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is an RFE with a possible implementation attached. The implementation does
not modify any existing code.

We're using HTTP POST to send a large amount of data with an unknown size. We
don't want to buffer the entire request, so we implemented a streaming POST
method. The implementation has 3 classes: StreamedPostMethod,
BufferedChunkedOutputStream and OutputStreamWriter. The bulk of the code is in
the BufferedChunkedOutputStream, which may be a good target for replacing
ChunkedOutputStream from the main distribution.

BufferedChunkedOutputStream has the following charactersitics:
1) It has an internal 2K buffer. Without the buffer, chunk sizes would be too
small in many cases (e.g. ObjectOutputStream likes to call write(byte[]) with 4
byte long arguments). 2K was chosen to minimize the chunk overhead to less than 1%.
2) If the entire entity body fits within the 2K buffer, it does not use
chunking. This implies that the headers are only sent out when the first chunk
(or the entire body) has to be written, but no sooner.
3) The chunk size is not limited to 2K: if write(byte[]) is called with a large
argument, the internal buffer and the new request are sent out as a single chunk.
4) Because of (2) it's tightly coupled to StreamedPostMethod.reallyWriteHeaders.
5) StreamedPostMethod calls BufferedChunkedOutputStream.finish() to write the
last buffer and ending chunk.

Because of 4 and 5, we didn't want to touch ChunkedOutputStream. Interestingly,
EntityEnclosingMethod is already tightly coupled to ChunkedOutputStream because
it has to call writeClosingChunk. There is probably some room for refactoring here.

The package is just a suggestion; feel free to move the files as appropirate.
This code was written against 2.0rc2. We're hoping it will get included in time
for the 2.1 release.

To use the code, you must implement OutputStreamWriter and pass it to
StreamedPostMethod's constructor. Execute the method as usual.

Caveats: StreamedPostMethod does not implement Expect/continue logic. We had no
way to test this. It is also strictly for POST. In general, the same methodology
is applicable to PUT, etc. It should be fairly simple to generalize.

Legal: Goldman, Sachs & Co. is making this code available under the Apache License.

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

DO NOT REPLY [Bug 20089] - Authentication fails with proxied SSL Connections

[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=20089

Authentication fails with proxied SSL Connections

This bug depends on bug 25529, which changed state:

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 10794] - User interaction for authentication

[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=10794

User interaction for authentication

This bug depends on bug 25529, which changed state:

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 18:51 ---
Patch committed. Oleg

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

Re: MultipartPostMethod Help!!

[Stéphane Houle]

Thank you Oleg & Mark for your help!!!

I'll write a workaround FilePart that do not convert the filename to 
us-ascii!!! 

Oleg:
if you fix the problem, can you send an email to me or to the mailing 
list please!  Thanks!

Steph

Oleg Kalnichevski wrote:

Is it a requirement that Disposition Header be in ASCII?

   

Yep. See RFC2183  and RFC1521
 for details

 Current [RFC 2045] grammar restricts parameter values (and hence
  Content-Disposition filenames) to US-ASCII.  We recognize the great
  desirability of allowing arbitrary character sets in filenames, but
  it is beyond the scope of this document to define the necessary
  mechanisms.  We expect that the basic [RFC 1521] `value'
  specification will someday be amended to allow use of non-US-ASCII
  characters, at which time the same mechanism should be used in the
  Content-Disposition filename parameter.


PS: As soon as I have a breathing moment I may contribute
quote-printable codec to Commons-codec, which would allow us to take
care of the problem
Cheers

Oleg

 

-Mark

Stéphane Houle wrote:

   

Hi everyone,

I'm very sorry to send an email directly to all of you but I saw your 
emails in the MultipartPostMethod source code in HttpClient 2.0 RC2.  
Maybe you can or cannot answer to my question, if not, do you know a 
mailing list or a person how can answer to my question ??

Here's my question:

I'm using MultipartPostMethod to send a file, everything works well but 
when the filename contains French character like "é", the character is 
always converted to ?.  I though it was the encoding that was setted to 
US-ASCII or something like that but no, the encoding is setted to 
ISO-8859-1.  I tried all sort to method to send the file:

- set the File object
- set the File object with the filename
- set a FilePart
- set a FilePart with a FilePartSource
Nothing works, here is a little dump of my Part:

FILE: /home/lhoule/dev/ac-httpClient-1.0/fileTest/toté.mp3
PART 0: ISO-8859-1
PART 0: binary
PART 0: application/octet-stream
PART 0: file
PART 0: 314159265358979323846
I don't know what I can do...  I try to search the web for a solution or 
in jakarta website...  Nothing...  Did you ever have this kind of 
problem??  Or maybe I don't use the MultipartPostMethod correctly to 
support French character??

Any clue?

Thank you very much and sorry again to send an email directly to all of you!

Steph
 



 

Re: refresh header proxy

[Ortwin Glück]

Roland Weber wrote:


It is common (maybe even standard?) behaviour for browsers to
interpret this meta tag, which does not mean they interpret the
corresponding HTTP header. 
Roland,

it may interest you that http-equiv meta parameters are actually meant 
to be treated as if they were sent as HTTP headers. So if the meta tag 
works in a browser, the HTTP header must work as well.

Odi

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

RE: refresh header proxy

[David Rosenstark]

I think I will assume that i misunderstood the problem based on Oleg's
response. What i meant was that i knew that this proxy was not causing a
problem to either of the browsers. What i found in my research was that this
header is not a standard http 1.1 header but supported by netscape and IE

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 5:18 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


Hello David,

are you sure the browsers are handling the HTTP header field and
not the contents of the HTML document returned? The syntax of
the header field resembles the typical HTML refresh statement:



It is common (maybe even standard?) behaviour for browsers to
interpret this meta tag, which does not mean they interpret the
corresponding HTTP header. The header never became a standard,
as pointed out by others.

Have you tried to return a Refresh: header for a document that
does definitely not contain the meta tag?

cheers,
  Roland






"David Rosenstark" <[EMAIL PROTECTED]>
12.01.2004 15:16
Please respond to "Commons HttpClient Project"

To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
cc:
Subject:RE: refresh header proxy


ok, good point. I tried out just resending the requests twice and it did
not
work, so it obviously needs to be studied more and would probably require
some additional headers be sent.
By studying the logs, i found that the proxy server must be blue coat.
One more thing. While it may not be standard - mozilla and IE handle this
header just fine.

I sent you the log (and not the list) as i was unsure whether the list
rules
would want something like that sent.

Thanks,
David

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 3:25 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


> I think all you need to know is what the header looks like, as i did
look
at
> the logs. It simply ignores the header. The header looks like this:
>
> Refresh: 0; URL=https://

Well, things _may_ be a little bit more complicated than that. Therefore,
the complete wirelog might be beneficial. Besides, the wirelog would also
tell me what proxy server you are using.

At the moment, having done some googling I failed to find any references
to
a 'refresh' header definition. If the header in question is a proprietary
feature of the proxy server that you are using, I doubt it warrants the
inclusion into the stock version of HttpClient. I believe the connection
refresh stuff can be easily  implemented with a little bit of code on top
of
standard HttpClient.

Oleg


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of
reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the
development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient
logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it
send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]


-
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: refresh header proxy

[Roland Weber]

Hello David,

are you sure the browsers are handling the HTTP header field and
not the contents of the HTML document returned? The syntax of
the header field resembles the typical HTML refresh statement:



It is common (maybe even standard?) behaviour for browsers to
interpret this meta tag, which does not mean they interpret the
corresponding HTTP header. The header never became a standard,
as pointed out by others.

Have you tried to return a Refresh: header for a document that
does definitely not contain the meta tag?

cheers,
  Roland 






"David Rosenstark" <[EMAIL PROTECTED]>
12.01.2004 15:16
Please respond to "Commons HttpClient Project"
 
To: "Commons HttpClient Project" 
<[EMAIL PROTECTED]>
cc: 
Subject:RE: refresh header proxy


ok, good point. I tried out just resending the requests twice and it did 
not
work, so it obviously needs to be studied more and would probably require
some additional headers be sent.
By studying the logs, i found that the proxy server must be blue coat.
One more thing. While it may not be standard - mozilla and IE handle this
header just fine.

I sent you the log (and not the list) as i was unsure whether the list 
rules
would want something like that sent.

Thanks,
David

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 3:25 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


> I think all you need to know is what the header looks like, as i did 
look
at
> the logs. It simply ignores the header. The header looks like this:
>
> Refresh: 0; URL=https://

Well, things _may_ be a little bit more complicated than that. Therefore,
the complete wirelog might be beneficial. Besides, the wirelog would also
tell me what proxy server you are using.

At the moment, having done some googling I failed to find any references 
to
a 'refresh' header definition. If the header in question is a proprietary
feature of the proxy server that you are using, I doubt it warrants the
inclusion into the stock version of HttpClient. I believe the connection
refresh stuff can be easily  implemented with a little bit of code on top 
of
standard HttpClient.

Oleg


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of 
reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the 
development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient 
logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it 
send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]


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

DO NOT REPLY [Bug 26060] New: - Log level for message should be debug instead of error.

[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=26060

Log level for message should be debug instead of error.

   Summary: Log level for message should be debug instead of error.
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In method org.apache.commons.httpclient.HttpMethodBase.getResponseBody() Log
message should be logged as debug instead of error. 

717 } catch (IOException e) {
718 LOG.error("I/O failure reading response body", e);
719 this.responseBody = null;
720 }

According to bug 10804:
2) Only/always log exception stack traces at the debug level
} catch (Exception ex) {
log.debug

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

RE: refresh header proxy

[David Rosenstark]

ok, thanks. I will try to give it a try and let you know if it helps.

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 4:37 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


All right. After having examined the wirelog you had sent me, I think I know
what is going on. It looks like it has noting to do with that 'refresh'
header. I believe you have been bitten by this bug:

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

The bad news is that HttpClient 2.0 will never be able to handle SSL via
proxy + host authentication due to severe design limitations. Your only
chance is to use preemptive authentication. See the SSL guide for more
details

http://jakarta.apache.org/commons/httpclient/sslguide.html

The good news is that the patch that should solve the problem for the
development (read unstable) version has been (coincidentally) just approved:

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

I'll commit the patch tonight. You may take to the next morning (that is,
CET morning) nightly build for a spin and see if that makes any difference

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 15:17
To: Commons HttpClient Project
Subject: RE: refresh header proxy


ok, good point. I tried out just resending the requests twice and it did not
work, so it obviously needs to be studied more and would probably require
some additional headers be sent.
By studying the logs, i found that the proxy server must be blue coat.
One more thing. While it may not be standard - mozilla and IE handle this
header just fine.

I sent you the log (and not the list) as i was unsure whether the list rules
would want something like that sent.

Thanks,
David

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 3:25 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


> I think all you need to know is what the header looks like, as i did look
at
> the logs. It simply ignores the header. The header looks like this:
>
> Refresh: 0; URL=https://

Well, things _may_ be a little bit more complicated than that. Therefore,
the complete wirelog might be beneficial. Besides, the wirelog would also
tell me what proxy server you are using.

At the moment, having done some googling I failed to find any references to
a 'refresh' header definition. If the header in question is a proprietary
feature of the proxy server that you are using, I doubt it warrants the
inclusion into the stock version of HttpClient. I believe the connection
refresh stuff can be easily  implemented with a little bit of code on top of
standard HttpClient.

Oleg


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]


-
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: refresh header proxy

[Kalnichevski, Oleg]

All right. After having examined the wirelog you had sent me, I think I know what is 
going on. It looks like it has noting to do with that 'refresh' header. I believe you 
have been bitten by this bug:

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

The bad news is that HttpClient 2.0 will never be able to handle SSL via proxy + host 
authentication due to severe design limitations. Your only chance is to use preemptive 
authentication. See the SSL guide for more details

http://jakarta.apache.org/commons/httpclient/sslguide.html
 
The good news is that the patch that should solve the problem for the development 
(read unstable) version has been (coincidentally) just approved: 

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

I'll commit the patch tonight. You may take to the next morning (that is, CET morning) 
nightly build for a spin and see if that makes any difference

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 15:17
To: Commons HttpClient Project
Subject: RE: refresh header proxy


ok, good point. I tried out just resending the requests twice and it did not
work, so it obviously needs to be studied more and would probably require
some additional headers be sent.
By studying the logs, i found that the proxy server must be blue coat.
One more thing. While it may not be standard - mozilla and IE handle this
header just fine.

I sent you the log (and not the list) as i was unsure whether the list rules
would want something like that sent.

Thanks,
David

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 3:25 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


> I think all you need to know is what the header looks like, as i did look
at
> the logs. It simply ignores the header. The header looks like this:
>
> Refresh: 0; URL=https://

Well, things _may_ be a little bit more complicated than that. Therefore,
the complete wirelog might be beneficial. Besides, the wirelog would also
tell me what proxy server you are using.

At the moment, having done some googling I failed to find any references to
a 'refresh' header definition. If the header in question is a proprietary
feature of the proxy server that you are using, I doubt it warrants the
inclusion into the stock version of HttpClient. I believe the connection
refresh stuff can be easily  implemented with a little bit of code on top of
standard HttpClient.

Oleg


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]


-
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 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 14:19 ---
Commit it fine with me.

Mike

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

Re: refresh header proxy

[Mike Moran]

Kalnichevski, Oleg wrote:
I think all you need to know is what the header looks like, as i did look at
the logs. It simply ignores the header. The header looks like this:
Refresh: 0; URL=https://


Well, things _may_ be a little bit more complicated than that. 
[ ... ]

I had to do some parsing of this type of header when writing a parser 
that extracted these from their in-html incarnation. At the time I 
couldn't find much out about them either. FWIW, the following regexp 
caught a lot of the html pages I saw in the wild:

;\s*[Uu][Rr][Ll]=\s*([^\s]+)\s*$

The main thing to watch out for was the variation in case of the "URL=" 
part. This may not be an issue if the header is generated by an actual 
http server (as opposed to being in some html or added by a CGI script).

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

RE: refresh header proxy

[David Rosenstark]

ok, good point. I tried out just resending the requests twice and it did not
work, so it obviously needs to be studied more and would probably require
some additional headers be sent.
By studying the logs, i found that the proxy server must be blue coat.
One more thing. While it may not be standard - mozilla and IE handle this
header just fine.

I sent you the log (and not the list) as i was unsure whether the list rules
would want something like that sent.

Thanks,
David

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 3:25 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


> I think all you need to know is what the header looks like, as i did look
at
> the logs. It simply ignores the header. The header looks like this:
>
> Refresh: 0; URL=https://

Well, things _may_ be a little bit more complicated than that. Therefore,
the complete wirelog might be beneficial. Besides, the wirelog would also
tell me what proxy server you are using.

At the moment, having done some googling I failed to find any references to
a 'refresh' header definition. If the header in question is a proprietary
feature of the proxy server that you are using, I doubt it warrants the
inclusion into the stock version of HttpClient. I believe the connection
refresh stuff can be easily  implemented with a little bit of code on top of
standard HttpClient.

Oleg


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]


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

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 13:52 ---
> The question is if the patch is step forward
> or backward. 

I think the code is moving towards the right places. It's certainly an
improvement. Good work so far.

> Unless we are talking about different things, I believe that this is in fact the
> case. There's _always_ (preemptive auth scheme notwithstanding) only one
> instance of authentication scheme within a complete authentication cycle.

Oh. So I have to look at it again. Then this is fine with me and I can try and
make DigestAuth behave better ,-)

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

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 13:36 ---

> I think the patch is okay, but the architecture is not perfect yet. You can
> still commit it I guess. I did not run any tests on it but rather scimmed the 
> code.

Things can be always done better. The question is if the patch is step forward
or backward. If you need more time to review the patch, let me know.

> 2. For real stateful authentication we will need a single AuthScheme instance
> that  lives during a complete authentication cycle. 

Unless we are talking about different things, I believe that this is in fact the
case. There's _always_ (preemptive auth scheme notwithstanding) only one
instance of authentication scheme within a complete authentication cycle. One
may take this one step further and persist (cache) authentication schemes
between method invocations to avoid re-authentication against the realms
HttpClient already has authenticated with. But this is something for 4.0

Oleg

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

RE: refresh header proxy

[Kalnichevski, Oleg]

> I think all you need to know is what the header looks like, as i did look at
> the logs. It simply ignores the header. The header looks like this:
> 
> Refresh: 0; URL=https://

Well, things _may_ be a little bit more complicated than that. Therefore, the complete 
wirelog might be beneficial. Besides, the wirelog would also tell me what proxy server 
you are using. 

At the moment, having done some googling I failed to find any references to a 
'refresh' header definition. If the header in question is a proprietary feature of the 
proxy server that you are using, I doubt it warrants the inclusion into the stock 
version of HttpClient. I believe the connection refresh stuff can be easily  
implemented with a little bit of code on top of standard HttpClient.

Oleg


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]

Re: refresh header proxy

[Ortwin Glück]

Kalnichevski, Oleg wrote:

There is not anything like a refresh header in HTTP. You probably mean 


Odi, that quite well may be, but to my best knowledge certain widely used proxy headers are not really defined by any RFCs. There are just common practices that most of the leading proxy servers adhere to (to an extent) like 'Proxy-connection' header. Refresh header may fall into such category of commonly used proxy headers. We should be able to tell if my theory is right by examining the wirelog of the session.
It's not specific to proxy at all. Refresh was introduced by Netscape 
1.1 and is not defined by any HTTP RFCs nowadays. You can still see it's 
original definition here: 
http://wp.netscape.com/assist/net_sites/pushpull.html

Odi

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

RE: refresh header proxy

[David Rosenstark]

I think these are teh relevant lines:

2004-01-12 15:21:14,406 [main] DEBUG httpclient.wire - << "Content-Type:
text/html[\r][\n]"
2004-01-12 15:21:14,406 [main] DEBUG httpclient.wire - << "Pragma:
no-cache[\r][\n]"
2004-01-12 15:21:14,406 [main] DEBUG httpclient.wire - << "Refresh: 0;
URL=https://reports..com/users//file.csv[\r][\n]";
2004-01-12 15:21:14,406 [main] DEBUG httpclient.wire - << "Connection:
Close[\r][\n]"

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:58 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


> There is not anything like a refresh header in HTTP. You probably mean

Odi, that quite well may be, but to my best knowledge certain widely used
proxy headers are not really defined by any RFCs. There are just common
practices that most of the leading proxy servers adhere to (to an extent)
like 'Proxy-connection' header. Refresh header may fall into such category
of commonly used proxy headers. We should be able to tell if my theory is
right by examining the wirelog of the session.

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]

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 13:18 ---
I think the patch is okay, but the architecture is not perfect yet. You can
still commit it I guess. I did not run any tests on it but rather scimmed the code.

To do:
1. I would like to get rid of the challenge stuff in AuthScheme interface.
Challenge is really an implementation detail that should not be part of this
interface.
2. For real stateful authentication we will need a single AuthScheme instance
that  lives during a complete authentication cycle. The
AuthPolicy::getAuthScheme method does not currently fulfill this.

Odi

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

RE: refresh header proxy

[David Rosenstark]

Thanks!

I think all you need to know is what the header looks like, as i did look at
the logs. It simply ignores the header. The header looks like this:

Refresh: 0; URL=https://

so, just as in 302 code where it follows the redirects, we would need to
have it follow this "redirect" and request the page.

Do you need more info than this?

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Mon, January 12, 2004 2:51 PM
To: Commons HttpClient Project
Subject: RE: refresh header proxy


David,
No, it is not. However, as we are currently in the process of reengineering
authentication/proxy code, if you provide the wirelog/debug of the HTTP
session in question, we might be able to add such feature to the development
branch of HttpClient in the forthcoming weeks

For details on logging in HttpClient please refer to the HttpClient logging
guide 

Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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: refresh header proxy

[Kalnichevski, Oleg]

> There is not anything like a refresh header in HTTP. You probably mean 

Odi, that quite well may be, but to my best knowledge certain widely used proxy 
headers are not really defined by any RFCs. There are just common practices that most 
of the leading proxy servers adhere to (to an extent) like 'Proxy-connection' header. 
Refresh header may fall into such category of commonly used proxy headers. We should 
be able to tell if my theory is right by examining the wirelog of the session.

Oleg

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

Re: refresh header proxy

[Ortwin Glück]

David Rosenstark wrote:

Is the refresh header supposed to be supported by httpclient (latest
version)?
There is not anything like a refresh header in HTTP. You probably mean 
the refresh feature of HTML. HTML is transported by HTTP as the message 
body. HttpClient does not try to interprete the message body and 
therefor does and will not support refresh.

I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.
Kind regards

Ortwin Glück

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

RE: refresh header proxy

[Kalnichevski, Oleg]

David,
No, it is not. However, as we are currently in the process of reengineering 
authentication/proxy code, if you provide the wirelog/debug of the HTTP session in 
question, we might be able to add such feature to the development branch of HttpClient 
in the forthcoming weeks 

For details on logging in HttpClient please refer to the HttpClient logging guide 


Cheers

Oleg

-Original Message-
From: David Rosenstark [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 13:47
To: Commons HttpClient Project
Subject: refresh header proxy


Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
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]

refresh header proxy

[David Rosenstark]

Is the refresh header supposed to be supported by httpclient (latest
version)?
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.

TIA,
David


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

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 12:39 ---
Created an attachment (id=9909)
Patch (take 2)

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

Re: Horseplay - https

[Charles Johnson]

Thanks Roland - that's a great start!

CJ
- Original Message -
From: "Roland Weber" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Monday, January 12, 2004 9:16 AM
Subject: Re: Horseplay - https


> Hello Charles,
>
> you suspect correctly, the login form comes from
> https://reg.racingpost.co.uk/cde/login_iframe.sd
> as you can easily verify by accessing that URL directly
> in your browser. From there, the login form is sent as
> a POST request to reg.racingpost.co.uk
>
> HttpClient can deal with the requests that need to be
> sent to the server. Unfortunately, there is plenty of
> JavaScript in www.racingpost.co.uk, and HttpClient
> won't help you with that. Also, the interaction between
> www.racingpost.co.uk and reg.racingpost.co.uk needs
> further analysis.
> In the easiest case, reg.racingpost.co.uk sets a cookie
> for .racingpost.co.uk as the result of the successful
> login. Then, you can use HttpClient without a problem.
>
> I suggest you try and send the equivalent of the POST
> request that is generated in the login IFrame and see
> what comes back. If you have problems with SSL
> support, you can refer to the SSL guide at
> http://jakarta.apache.org/commons/httpclient/sslguide.html
> and to the mailing list archives.
>
> cheers,
>   Roland
>
>
>
>
>
>
>
> "Charles Johnson" <[EMAIL PROTECTED]>
> 11.01.2004 21:44
> Please respond to "Commons HttpClient Project"
>
> To: "Commons HttpClient Project"
> <[EMAIL PROTECTED]>
> cc:
> Subject:Horseplay - https
>
>
> My objective is to log in to this site using httpclient:
>
> http://www.racingpost.co.uk/horses
>
> The first problem is that I can't see the connection between the following
> request (gleaned from my browser + proxy) and the login form you see at
> the
> top of the page. Evidently this GET request (why no POST?) has an
> encrypted
> parameter string. Where has it come from? Where has the parameter name
> come
> from? Is it anything to do with this, which is in the page?:
>
> https://reg.racingpost.co.uk/cde/login_iframe.sd"; etc.
>
> Can httpclient cope?
>
>
> Here's the request:
>
> 2. Then log in using the button at the top:
> --
> REQUEST
> ---
> GET
> /horses/?MIval=rp_reg_init&TMP_CK_CK=%7Fv%7Dw5u%2F2%23%24%22VML%5BCUGBJY
> HTTP/1.1
> Host: www.racingpost.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4)
> Gecko/20011128 Netscape6/6.2.1
> Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,
> image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,
> */*;q=0.1
> Accept-Language: en-gb
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: utf-8, *
> Keep-Alive: 300
> Cookie: session.ID=IDa200fff6130d72; PermRpLogin=httpclient
>
>
> -
> 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 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 11:19 ---
sorry Oleg, I can not apply the patch to the current HEAD. It seems outdated.

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

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[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=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-01-12 11:04 ---
> HttpMethodDirector is quite complicated now,  more javadocs here would
> be quite helpful.

That goes without saying. As soon as the code stabilizes somewhat Javadocs will 
be provided. I would wait until the first alpha, though

> Granted, it is deprecated, but now it's completely non-functional.
> Any thoughts about how we can fix this?

I can't think of anything elegant, but a dirty workaround should not be too 
difficult.

Folks, are there any objections to committing the patch? Odi, have you had a 
change to review the patch? Are you still planning on reviewing it?

Oleg

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

Re: Horseplay - https

[Roland Weber]

Hello Charles,

you suspect correctly, the login form comes from
https://reg.racingpost.co.uk/cde/login_iframe.sd
as you can easily verify by accessing that URL directly
in your browser. From there, the login form is sent as
a POST request to reg.racingpost.co.uk

HttpClient can deal with the requests that need to be
sent to the server. Unfortunately, there is plenty of
JavaScript in www.racingpost.co.uk, and HttpClient
won't help you with that. Also, the interaction between
www.racingpost.co.uk and reg.racingpost.co.uk needs
further analysis.
In the easiest case, reg.racingpost.co.uk sets a cookie
for .racingpost.co.uk as the result of the successful
login. Then, you can use HttpClient without a problem.

I suggest you try and send the equivalent of the POST
request that is generated in the login IFrame and see
what comes back. If you have problems with SSL
support, you can refer to the SSL guide at
http://jakarta.apache.org/commons/httpclient/sslguide.html
and to the mailing list archives.

cheers,
  Roland







"Charles Johnson" <[EMAIL PROTECTED]>
11.01.2004 21:44
Please respond to "Commons HttpClient Project"
 
To: "Commons HttpClient Project" 
<[EMAIL PROTECTED]>
cc: 
Subject:Horseplay - https


My objective is to log in to this site using httpclient:

http://www.racingpost.co.uk/horses

The first problem is that I can't see the connection between the following
request (gleaned from my browser + proxy) and the login form you see at 
the
top of the page. Evidently this GET request (why no POST?) has an 
encrypted
parameter string. Where has it come from? Where has the parameter name 
come
from? Is it anything to do with this, which is in the page?:

https://reg.racingpost.co.uk/cde/login_iframe.sd"; etc.

Can httpclient cope?


Here's the request:

2. Then log in using the button at the top:
--
REQUEST
---
GET 
/horses/?MIval=rp_reg_init&TMP_CK_CK=%7Fv%7Dw5u%2F2%23%24%22VML%5BCUGBJY
HTTP/1.1
Host: www.racingpost.co.uk
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4)
Gecko/20011128 Netscape6/6.2.1
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,
image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,
*/*;q=0.1
Accept-Language: en-gb
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: utf-8, *
Keep-Alive: 300
Cookie: session.ID=IDa200fff6130d72; PermRpLogin=httpclient


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