handle multivalue headers correctly

[Jeffrey Dever]

Hi Mike,

I'm still concerned about having public methods in HttpMethodBase that 
are not in the HttpMethod interface.  These two public interfaces should 
not diverge.  I had this same problem in a the past, where I added a 
public method to the abstract class, and not the interface.  Then I saw 
user code that was casting from the nice interface to the abstract class 
to access services that were not supposed to be accessed.

So I like the idea of a HeaderGroup, but don't like public additions to 
the HttpMethodBase class.  So when I said that it would be desirable to 
make no chages to the HttpMethod interface, that includes public changes 
to HttpMethodBase.

One other note, we use the terminology "footers" as headers that can be 
at the end of a chunked body.  The RFC terminology is really "trailers". 
While footers has been used for a while in HttpClient, and the term is 
arbitrairy, we probablly should migrate to the RFC terminology.

The factoring out of the readLine details looks good.  HeaderParser 
should go into the util/ subpackage.

Jandalf.


--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 23:18 ---
Attached previously is a second attempt at fixing this problem.  Here's what's new:

- HttpMethod no longer has any changes
- @since 2.0beta1 tags have been added
- absolute @see and @link tags been made relative
- a static HttpConnection.readLine(InputStream) method has been added and is
being used by HttpConnection and HeaderParser.
- HeaderGroup.getCondensedHeader() now always returns a new Header

 




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

handle multivalue headers correctly

[Jeffrey Dever]

Hi Mike,

I'm concerned about having public methods in HttpMethodBase that
are not in the HttpMethod interface.  These two public interfaces should
not diverge.  I had this same problem in the past, where I added a
 public method to the abstract class, and not the interface.  Then I saw
user code that was casting from the nice interface to the abstract class
to access services that were not supposed to be accessed.

So I like the idea of a HeaderGroup, but don't like public additions to
the HttpMethodBase class.  So when I said that it would be desirable to
make no chages to the HttpMethod interface, that includes public changes
to HttpMethodBase.

One other note, we use the terminology "footers" as headers that can be
at the end of a chunked body.  The RFC terminology is really "trailers".
 While footers has been used for a while in HttpClient, and the term is
arbitrairy, we probablly should migrate to the RFC terminology if possible.

Jandalf.


>--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 
23:18 ---
>Attached previously is a second attempt at fixing this problem. 
Here's what's new:
>
> - HttpMethod no longer has any changes
> - @since 2.0beta1 tags have been added
> - absolute @see and @link tags been made relative
> - a static HttpConnection.readLine(InputStream) method has been added 
and is
>being used by HttpConnection and HeaderParser.
> - HeaderGroup.getCondensedHeader() now always returns a new Header
>
>
>




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

Re: DO NOT REPLY [Bug 11218] - handle multivalue headerscorrectly

[Oleg Kalnichevski]

Mike,

Looks really good to me. It's a welcome improvement, which will finally
allow for cookies to be put on a separate header line each

Great work!!!

Oleg

On Sun, 2003-02-09 at 00:18, [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=11218
> 
> handle multivalue headers correctly
> 
> 
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED]  2003-02-08 23:18 ---
> Attached previously is a second attempt at fixing this problem.  Here's what's new:
> 
>  - HttpMethod no longer has any changes
>  - @since 2.0beta1 tags have been added
>  - absolute @see and @link tags been made relative
>  - a static HttpConnection.readLine(InputStream) method has been added and is
> being used by HttpConnection and HeaderParser.
>  - HeaderGroup.getCondensedHeader() now always returns a new Header
> 
> Enjoy,
> 
> 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]

DO NOT REPLY [Bug 11218] - handle multivalue headers 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=11218

handle multivalue headers correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 23:18 ---
Attached previously is a second attempt at fixing this problem.  Here's what's new:

 - HttpMethod no longer has any changes
 - @since 2.0beta1 tags have been added
 - absolute @see and @link tags been made relative
 - a static HttpConnection.readLine(InputStream) method has been added and is
being used by HttpConnection and HeaderParser.
 - HeaderGroup.getCondensedHeader() now always returns a new Header

Enjoy,

Mike

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

DO NOT REPLY [Bug 11218] - handle multivalue headers 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=11218

handle multivalue headers correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 23:12 ---
Created an attachment (id=4792)
Proposed solution, try 2

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

Re: DO NOT REPLY [Bug 16892] New: - Empty response body is notproperly handled when chunked encoding is used

[Oleg Kalnichevski]

Odi, Jeff
I tend to interpret the word of RFC the same way. However, the RFC
appears a bit fuzzy on whether it is permissible to include
"Transfer-Encoding: chunked" response header without actually providing
any content in response. Anyways, to an extent this is irrelevant. We
have to coexist with IIS regardless of its lousy standards compliance
record

Oleg 


On Sat, 2003-02-08 at 14:21, Ortwin Glück wrote:
> If a Transfer-Encoding: chunked header is present, the body must at 
> least contain the last chunk, which is:
> 
> 0
> 
> 
> Without the last chunk beeing present we can not detect if there is a 
> body at all! The last chunk not beeing present violates the RFC: 
> last-chunk has no asterix in front of it.
> 
> Odi
> 
> 
> -
> 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: supported jre version [was Re: Propose a new commons-uri package]

[Jeffrey Dever]

Good point.  In general, the examples should also baseline jdk1.2.  If 
there is a specific reason for using a 1.3 or 1.4 feature in some case, 
than that would be OK as long as its clearly stated.  

We would have to deal with that on a compilation level somehow as well.

Jandalf.


Oleg Kalnichevski wrote:

Jandalf

I have no problem compiling HttpClient with JDK 1.2.2 + JCE 1.2.2 + JSSE
1.0.3.01, as well as test cases. However, several examples require newer
JDK: PostXML, ClientApp, MultiPartUploadApp. Do you think examples
should also be JDK 1.2.2 compatible? I tend to believe they should

Cheers

Oleg (Olegolas) 



On Fri, 2003-02-07 at 23:16, Jeffrey Dever wrote:
 

Agreed.  If we were building an application, then we could arbitrairly 
decide to use whichever jre version that was most suitable. But we are 
not building an application, we are building a framework.  As a result 
we must support the lowest reasonable version.  This has always been 
jre1.2.x

Which reminds me, next time I better actually compile the release build 
with 1.2 ... I'll update the release process.

Jandalf.


Oleg Kalnichevski wrote:

   

I am also of opinion that for the time being Java 1.2.2 should be
considered the lowest common denominator. Doing otherwise would
completely preclude several major platforms from being able to run
HttpClient. Please correct me if I err, but as far as I know IBM only
supports Java 1.3.1 on its operating systems (such as AIX), with IBM
Java 1.4.1 still being in beta. Mac OS X does not support Java 1.4.1
either, at least not yet. The use of Java 1.4.1 specific features should
be ruled out for a few years to come (IMHO)

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]


 




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

Re: supported jre version [was Re: Propose a new commons-uripackage]

[Oleg Kalnichevski]

Jandalf

I have no problem compiling HttpClient with JDK 1.2.2 + JCE 1.2.2 + JSSE
1.0.3.01, as well as test cases. However, several examples require newer
JDK: PostXML, ClientApp, MultiPartUploadApp. Do you think examples
should also be JDK 1.2.2 compatible? I tend to believe they should

Cheers

Oleg (Olegolas) 



On Fri, 2003-02-07 at 23:16, Jeffrey Dever wrote:
> Agreed.  If we were building an application, then we could arbitrairly 
> decide to use whichever jre version that was most suitable. But we are 
> not building an application, we are building a framework.  As a result 
> we must support the lowest reasonable version.  This has always been 
> jre1.2.x
> 
> Which reminds me, next time I better actually compile the release build 
> with 1.2 ... I'll update the release process.
> 
> Jandalf.
> 
> 
> Oleg Kalnichevski wrote:
> 
> >I am also of opinion that for the time being Java 1.2.2 should be
> >considered the lowest common denominator. Doing otherwise would
> >completely preclude several major platforms from being able to run
> >HttpClient. Please correct me if I err, but as far as I know IBM only
> >supports Java 1.3.1 on its operating systems (such as AIX), with IBM
> >Java 1.4.1 still being in beta. Mac OS X does not support Java 1.4.1
> >either, at least not yet. The use of Java 1.4.1 specific features should
> >be ruled out for a few years to come (IMHO)
> >
> >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]

DO NOT REPLY [Bug 16412] - Using a deprecated URLEncoder method

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

Using a deprecated URLEncoder method

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 20:21 ---
HttpClient requires jdk1.2.x as its baseline runtime.  Deprecation warnings of
this nature may be unavoidable.  This is a non-issue.

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

DO NOT REPLY [Bug 16429] - Align the code base with checkstyle

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

Align the code base with checkstyle

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 20:19 ---
I'd call this feature complete.  There are still some non-compliant classes,
(like URI) but these are slated to be factored into their own package.  The
remaining violations are generally useful (such as TODO comments) and will be
corrected over time.

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

DO NOT REPLY [Bug 16907] - Introduce Aspect oriented programming

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

Introduce Aspect oriented programming

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
   Target Milestone|--- |2.1 Final

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

DO NOT REPLY [Bug 16907] New: - Introduce Aspect oriented programming

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

Introduce Aspect oriented programming

   Summary: Introduce Aspect oriented programming
   Product: Commons
   Version: 2.0 Alpha 2
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


HttpClient uses logging extensively to provide exeuction trace.  Each method has
(or is supposed to have) an log at its entry point.  This is a classic "cross
cutting concern" that is well solved by aspect oriented programming tecniques.

AspectJ is well supporte in Maven and is used in a number of other Jakarta
projects, notably Cactus.

Consider introducing aspects to HttpClient.

-
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

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||commons-httpclient-
   ||[EMAIL PROTECTED]
 Status|NEW |ASSIGNED
   Target Milestone|2.0 Beta 1  |2.0 Beta 2



--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 20:11 ---
Need to provide a walkthrough of the API, standard practices tuned for a new user.

Example code is handled under another bug.

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

DO NOT REPLY [Bug 16861] - Digest Authentication fails with Microsoft ISA, appears hung to user

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

Digest Authentication fails with Microsoft ISA, appears hung to user

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Beta 1

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

DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports

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

Allow redirects between hosts and ports

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Beta 2

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

DO NOT REPLY [Bug 16892] - Empty response body is not properly handled when chunked encoding is used

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

Empty response body is not properly handled when chunked encoding is used

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

DO NOT REPLY [Bug 16892] - Empty response body is not properly handled when chunked encoding is used

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

Empty response body is not properly handled when chunked encoding is used

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Beta 1
Version|2.0 Alpha 1 |2.0 Alpha 2

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

RE: DO NOT REPLY [Bug 16904] - Input Stream closed, Output Stream valid, no detection by socket

[Nick Coleman]

Thank you for the directions for how to submit this problem...  Attached are
the file I created.

> Feedback to your patch:
> It will buffer the whole response which is not good. Imagine a 1GB
response. You would not want this to be buffered, would you.

By using the Piped Streams I have limited the buffer size haven't I?

>thread.interrupt() does not kill a thread. It only sets the interrupted
flag. You are not checking for this flag. So the >interrupt call will stay
unnoticed.

You're right about this, but at some point the input stream will be closed
and thread will exit. (It's definitely not the most elegant way...

I'll try to work on a test case in the meantime.





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

DO NOT REPLY [Bug 16904] - Input Stream closed, Output Stream valid, no detection by socket

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

Input Stream closed, Output Stream valid, no detection by socket

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 16:47 ---
Reporter,

please subscribe to the mailing list:

List-Unsubscribe: 
List-Subscribe: 

Describe your bug there. Provide a test case if possible. Patches are usually
sent to the list in unidiff format, dicussed and approved before checked in.

Feedback to your patch:
It will buffer the whole response which is not good. Imagine a 1GB response. You
would not want this to be buffered, would you.
thread.interrupt() does not kill a thread. It only sets the interrupted flag.
You are not checking for this flag. So the interrupt call will stay unnoticed.

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

DO NOT REPLY [Bug 16904] New: - Input Stream closed, Output Stream valid, no detection by socket

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

Input Stream closed, Output Stream valid, no detection by socket

   Summary: Input Stream closed, Output Stream valid, no detection
by socket
   Product: Commons
   Version: 2.0 Alpha 2
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Before I say anything, I apologize if this is the wrong way to submit patches. 
I found this bug and wanted to upload the fix I made.

Periodically after a timeout, I can attempt to make a request on a connection 
that is still open.  The post is successfull, a tunnel host shows that the 
response is returned, but the HttpConnection class receives no data when trying 
to read from the socket input stream.  

This can be reproduced by creating a client connection, having the client be 
inactive for a short period of time (~30 sec) and accessing again.  If the 
client waits too long, the socket is closed and recovery is done correctly.

In the HttpMethodBase.readStatusLine method, I attempted to check all the new 
socket 1.4 flags before reading from the socket, but they all state that the 
stream is still valid.  However, the first line it attempts to read is the 
response code and -1 is immediately returned from the stream.

To put a hack in for this, I created a stream wrapper for the input stream that 
constantly looks for input data.  It can set a boolean flag indicating if it is 
still physically connected to the server.  Before any of the write routines 
actually write data to the output stream, they query this flag and throw an 
HttpRecoverableException if it is not connected.

The query for still connected was inserted into the methods:
HttpConnection.write(byte[] data, int offset, int length)
HttpConnection.writeLine()
HttpConnection.writeLine(byte[] data)

The code snippet to check is
--
if (!_input.isConnected()) {
  log.debug("HttpConnection: InputStream is no longer connected to server");
  throw new HttpRecoverableException("No longer connected to server");
}
-



The following is the code from the HttpInputStream class:
package org.apache.commons.httpclient;

import java.io.*;

public class HttpInputStream extends InputStream {
private InputStream in;
private PipedInputStream pin;
private PipedOutputStream pout;
private IOException readingException;
private boolean connected;
private StreamTask task;
private Thread thread;

/**
 * Constructor
 */
public HttpInputStream(InputStream in) throws IOException {
this.in = in;
this.pin = new PipedInputStream();
this.pout = new PipedOutputStream(pin);
this.connected = true;
this.task = new StreamTask();
this.thread = new Thread(task, "HTTP InputStream Wrapper");

thread.setDaemon(true);
thread.start();
}

/**
 * Closes the input stream
 */
public void close() throws IOException {
if (in == null)
throw new IOException("Stream not open.");

try{
// Kill thread if running
IOException iox = readingException;
if (thread.isAlive()) {
thread.interrupt();
}

// Throw any outstanding IO Exceptions
if (iox != null) throw iox;

// Try to close input stream normally
InputStream tmp = in;
in = null;
tmp.close();
}
catch(IOException iox){
throw iox;
}
finally {
try{ if (in!=null) in.close(); } catch (Exception ignored){}
try{ pin.close(); } catch (Exception ignored){}
try{ pout.close(); } catch (Exception ignored){}
}
}

/**
 * Executes the current task
 */
private void execute() {
Thread t = new Thread(task, "HTTP InputStream Wrapper");
t.setDaemon(true);
t.start();
}

/**
 * Returns true if stream is connected to server
 */
public boolean isConnected() {
return this.connected;
}

// Helper class
private class StreamTask implements Runnable {
public void run() {
byte buffer[] = new byte[1024];

try {
int ch = in.read();
while (ch >= 0) {
pout.write(ch);
int available = in.available();
if (available>0){
int toRead = (buffer.

Re: DO NOT REPLY [Bug 16892] New: - Empty response body is notproperly handled when chunked encoding is used

[Ortwin Glück]

If a Transfer-Encoding: chunked header is present, the body must at 
least contain the last chunk, which is:

0


Without the last chunk beeing present we can not detect if there is a 
body at all! The last chunk not beeing present violates the RFC: 
last-chunk has no asterix in front of it.

Odi


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

DO NOT REPLY [Bug 16864] - NullPointerException thrown when invalid header encountered

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

NullPointerException thrown when invalid header encountered

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||REMIND

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

DO NOT REPLY [Bug 14643] - duplicate code for redirection

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

duplicate code for redirection

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-02-08 08:51 ---
Merger of HttpClient and HttpMultiClient has solved the replicated code issue.

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

Re: DO NOT REPLY [Bug 16892] New: - Empty response body is notproperly handled when chunked encoding is used

[Jeffrey Dever]

2068 has been replaced by 2616, so I'll use that as the basis for this 
discussion.  

To determine if this is compliant behaviour, there are a couple of 
questions to answer.
1) Does a empty body qualify  as a chunked body?

  Chunked-Body   = *chunk
   last-chunk
   trailer
   CRLF   
  chunk  = chunk-size [ chunk-extension ] CRLF
   chunk-data CRLF
  chunk-size = 1*HEX
  last-chunk = 1*("0") [ chunk-extension ] CRLF

  chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
  chunk-ext-name = token
  chunk-ext-val  = token | quoted-string
  chunk-data = chunk-size(OCTET)
  trailer= *(entity-header CRLF)


I don't quite know what a "last-chunk" is, but is is not optional, nor 
is the CRLF.  So this says to me that a chunked body cannot be an empty 
body.  

2) But does a response to a POST require a body at all?

  The action performed by the POST method might not result in a
  resource that can be identified by a URI. In this case, either 200
  (OK) or 204 (No Content) is the appropriate response status,
  depending on whether or not the response includes an entity that
  describes the result.

Clearly a 200 response should have a body.  If there is no body, a 204 
should be returned.

So I would conclude that IIS is violating the standard in this regard. 
But we still have to cope with Microcruft non-standard, non-compliant, 
buggy behaviour.

Jeff Dever



Oleg Kalnichevski wrote:

Folks

I am not certain if this kind of behavior is in violation of the RFC
2068. Any opinions?

Oleg

On Fri, 2003-02-07 at 22:44, [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=16892

Empty response body is not properly handled when chunked encoding is used

  Summary: Empty response body is not properly handled when chunked
   encoding is used
  Product: Commons
  Version: 2.0 Alpha 1
 Platform: All
   OS/Version: All
   Status: NEW
 Severity: Major
 Priority: Other
Component: HttpClient
   AssignedTo: [EMAIL PROTECTED]
   ReportedBy: [EMAIL PROTECTED]


IIS 5.0 server, when returning no content in response to an HTTP/1.1 request,
still includes "Transfer-Encoding: chunked" response header. As HttpClient
always expects chunk-encoded stream to be properly terminated, an
HttpRecoverableException exception results, when no content is sent back

=

POST /someurl.aspx HTTP/1.1
Content-Length: 1132
Host: xxx.xxx.xxx.xxx
User-Agent: Jakarta Commons-HttpClient/2.0alpha2
Content-Type: multipart/form-data; boundary=314159265358979323846

--314159265358979323846
Content-Disposition: form-data; name="nmFile"; filename="x.xml"
Content-Type: application/octet-stream

<... content removed ...>

--314159265358979323846--

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sat, 08 Feb 2003 15:22:26 GMT
Transfer-Encoding: chunked
Cache-Control: private
Content-Type: text/html

=

Bug reported by Jim Crossley

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