You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Denis Valdenaire (JIRA)" <ji...@apache.org> on 2006/09/15 12:35:22 UTC

[jira] Created: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers

Http Client does not fix incorrect content-lenght headers
---------------------------------------------------------

                 Key: HTTPCLIENT-600
                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
             Project: HttpComponents HttpClient
          Issue Type: Improvement
          Components: HttpClient
    Affects Versions: 3.1 Alpha 1
         Environment: All
            Reporter: Denis Valdenaire


I discovered that the method 

addContentLengthRequestHeader (found in file methods/MultipartPostMethod.java) doesn't "fix" the content-lenght when this one is incorrect. It adds one if getRequestHeader("Content-Lenght") is null, but it should also verify that the content-lenght is correct.

I suggest something like :

long len = getRequestContentLength();
if (getRequestHeader("Content-Length") == null || getRequestHeader("Content-Length") != len) { 
            setRequestHeader("Content-Length", String.valueOf(len));
}

Sending an incorrect Content-Length blocks the server if the string sent is smaller than announced : waiting for more, and finally reset the connection. If it's too big, you lose data.

I've seen this problem in a reverse proxy program (with httpclient communicating with the real servers) when the client send urlencoded data and this data is modified (partly urldecoded) but not the content-lenght.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


[jira] Commented: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers

Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/HTTPCLIENT-600?page=comments#action_12434962 ] 
            
Roland Weber commented on HTTPCLIENT-600:
-----------------------------------------

Hi Denis,

HttpClient behaves exactly as intended. If there is no Content-Length header, HttpClient tries to compute one.
If you think you know better what the Content-Length header should be, and set it explicitly, then you do so on
your own risk and responsibility. HttpClient will not modify headers that were set explicitly. That's mainly because
somebody might have to create requests that are actually invalid, but are similar to what some other, broken
HTTP application generates. If you want HttpClient to provide the content length, then just don't set it. If you
want to verify the value you set, then use RequestEntity.getContentLength() in your application.

Reverse proxies are supposed to know which headers can be sent on and which can not. A proxy that
modifies the request entity is also responsible for updating all entity headers that might be affected by
that change. Please open an issue against the reverse proxy program that misbehaves.

I suggest to mark this issue invalid.

cheers,
  Roland


> Http Client does not fix incorrect content-lenght headers
> ---------------------------------------------------------
>
>                 Key: HTTPCLIENT-600
>                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 3.1 Alpha 1
>         Environment: All
>            Reporter: Denis Valdenaire
>
> I discovered that the method 
> addContentLengthRequestHeader (found in file methods/MultipartPostMethod.java) doesn't "fix" the content-lenght when this one is incorrect. It adds one if getRequestHeader("Content-Lenght") is null, but it should also verify that the content-lenght is correct.
> I suggest something like :
> long len = getRequestContentLength();
> if (getRequestHeader("Content-Length") == null || getRequestHeader("Content-Length") != len) { 
>             setRequestHeader("Content-Length", String.valueOf(len));
> }
> Sending an incorrect Content-Length blocks the server if the string sent is smaller than announced : waiting for more, and finally reset the connection. If it's too big, you lose data.
> I've seen this problem in a reverse proxy program (with httpclient communicating with the real servers) when the client send urlencoded data and this data is modified (partly urldecoded) but not the content-lenght.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


[jira] Commented: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers

Posted by "Denis Valdenaire (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/HTTPCLIENT-600?page=comments#action_12434984 ] 
            
Denis Valdenaire commented on HTTPCLIENT-600:
---------------------------------------------

Thanks for you answer. 

I had this idea because i saw it in a perl module (lwp). I tried to send incorrect content-lenght to emulate the behaviour of a broken client but the perl code corrected it. So i had to modify the lib so it doesn't modify it.

At least can we just issue a warning and not change it ? 

I agree that the content-length should not be modified if set explicitly but if false, it will cause an error that won't be easy to find. The warning (of debug, or trace) could help and will not modify the behaviour of the class.

But again, you're right, the program should not set - or forward the content-length if unsure.

Denis

> Http Client does not fix incorrect content-lenght headers
> ---------------------------------------------------------
>
>                 Key: HTTPCLIENT-600
>                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 3.1 Alpha 1
>         Environment: All
>            Reporter: Denis Valdenaire
>
> I discovered that the method 
> addContentLengthRequestHeader (found in file methods/MultipartPostMethod.java) doesn't "fix" the content-lenght when this one is incorrect. It adds one if getRequestHeader("Content-Lenght") is null, but it should also verify that the content-lenght is correct.
> I suggest something like :
> long len = getRequestContentLength();
> if (getRequestHeader("Content-Length") == null || getRequestHeader("Content-Length") != len) { 
>             setRequestHeader("Content-Length", String.valueOf(len));
> }
> Sending an incorrect Content-Length blocks the server if the string sent is smaller than announced : waiting for more, and finally reset the connection. If it's too big, you lose data.
> I've seen this problem in a reverse proxy program (with httpclient communicating with the real servers) when the client send urlencoded data and this data is modified (partly urldecoded) but not the content-lenght.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


[jira] Resolved: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers

Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HTTPCLIENT-600?page=all ]

Oleg Kalnichevski resolved HTTPCLIENT-600.
------------------------------------------

    Resolution: Invalid

I concur.

Oleg

> Http Client does not fix incorrect content-lenght headers
> ---------------------------------------------------------
>
>                 Key: HTTPCLIENT-600
>                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 3.1 Alpha 1
>         Environment: All
>            Reporter: Denis Valdenaire
>
> I discovered that the method 
> addContentLengthRequestHeader (found in file methods/MultipartPostMethod.java) doesn't "fix" the content-lenght when this one is incorrect. It adds one if getRequestHeader("Content-Lenght") is null, but it should also verify that the content-lenght is correct.
> I suggest something like :
> long len = getRequestContentLength();
> if (getRequestHeader("Content-Length") == null || getRequestHeader("Content-Length") != len) { 
>             setRequestHeader("Content-Length", String.valueOf(len));
> }
> Sending an incorrect Content-Length blocks the server if the string sent is smaller than announced : waiting for more, and finally reset the connection. If it's too big, you lose data.
> I've seen this problem in a reverse proxy program (with httpclient communicating with the real servers) when the client send urlencoded data and this data is modified (partly urldecoded) but not the content-lenght.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


[jira] Commented: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers

Posted by "Denis Valdenaire (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/HTTPCLIENT-600?page=comments#action_12434990 ] 
            
Denis Valdenaire commented on HTTPCLIENT-600:
---------------------------------------------

Hello Roland,

At the very least I will try to document it somewhere as a possible cause for a socket reset at the server side. We had a very hard time to debug this and only tcpdump was our friend....

Thanks for your help.

Best regards,

Denis

> Http Client does not fix incorrect content-lenght headers
> ---------------------------------------------------------
>
>                 Key: HTTPCLIENT-600
>                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 3.1 Alpha 1
>         Environment: All
>            Reporter: Denis Valdenaire
>
> I discovered that the method 
> addContentLengthRequestHeader (found in file methods/MultipartPostMethod.java) doesn't "fix" the content-lenght when this one is incorrect. It adds one if getRequestHeader("Content-Lenght") is null, but it should also verify that the content-lenght is correct.
> I suggest something like :
> long len = getRequestContentLength();
> if (getRequestHeader("Content-Length") == null || getRequestHeader("Content-Length") != len) { 
>             setRequestHeader("Content-Length", String.valueOf(len));
> }
> Sending an incorrect Content-Length blocks the server if the string sent is smaller than announced : waiting for more, and finally reset the connection. If it's too big, you lose data.
> I've seen this problem in a reverse proxy program (with httpclient communicating with the real servers) when the client send urlencoded data and this data is modified (partly urldecoded) but not the content-lenght.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


[jira] Commented: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers

Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/HTTPCLIENT-600?page=comments#action_12434986 ] 
            
Roland Weber commented on HTTPCLIENT-600:
-----------------------------------------

Hello Denis,

we won't add a String-to-int conversion (with exception handling for invalid numbers) just to generate a warning.
Besides, we had other users complaining about warnings that were generated about something they wanted
to do on purpose. Again: if you want the content length to be verified, please implement that in your application.

cheers,
  Roland


> Http Client does not fix incorrect content-lenght headers
> ---------------------------------------------------------
>
>                 Key: HTTPCLIENT-600
>                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 3.1 Alpha 1
>         Environment: All
>            Reporter: Denis Valdenaire
>
> I discovered that the method 
> addContentLengthRequestHeader (found in file methods/MultipartPostMethod.java) doesn't "fix" the content-lenght when this one is incorrect. It adds one if getRequestHeader("Content-Lenght") is null, but it should also verify that the content-lenght is correct.
> I suggest something like :
> long len = getRequestContentLength();
> if (getRequestHeader("Content-Length") == null || getRequestHeader("Content-Length") != len) { 
>             setRequestHeader("Content-Length", String.valueOf(len));
> }
> Sending an incorrect Content-Length blocks the server if the string sent is smaller than announced : waiting for more, and finally reset the connection. If it's too big, you lose data.
> I've seen this problem in a reverse proxy program (with httpclient communicating with the real servers) when the client send urlencoded data and this data is modified (partly urldecoded) but not the content-lenght.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org