[ 
https://issues.apache.org/jira/browse/TS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101908#comment-14101908
 ] 

Masakazu Kitajo commented on TS-2902:
-------------------------------------

[~bcall]

I tested again with latest source code on master branch, and it works for me.

Your test shows status code 400. It should be 411 if you apply the patch as is.
Would you test it again?

Here are my tests:

{noformat}
$ ./bin/traffic_line -r proxy.config.http.post.check.content_length.enabled
1
$ curl -v -s -d@foo  -x localhost:8080  -H "Content-Length: " -o /dev/null 
"http://www.yahoo.co.jp/";
* About to connect() to proxy localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
> POST http://www.yahoo.co.jp/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 
> zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.yahoo.co.jp
> Accept: */*
> Proxy-Connection: Keep-Alive
> Content-Type: application/x-www-form-urlencoded
> 
< HTTP/1.1 411 Content Length Required
< Date: Tue, 19 Aug 2014 05:43:36 GMT
< Connection: close
< Server: ATS/5.1.0
< Cache-Control: no-store
< Content-Type: text/html
< Content-Language: en
< Content-Length: 277
< 
{ [data not shown]
* Closing connection #0
{noformat}

{noformat}
$ ./bin/traffic_line -r proxy.config.http.post.check.content_length.enabled
0
$ curl -v -s -d@foo  -x localhost:8080  -H "Content-Length: " -o /dev/null 
"http://www.yahoo.co.jp/";
* About to connect() to proxy localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
> POST http://www.yahoo.co.jp/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 
> zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.yahoo.co.jp
> Accept: */*
> Proxy-Connection: Keep-Alive
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Server: ATS/5.1.0
< Date: Tue, 19 Aug 2014 05:43:21 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 4058
< P3P: policyref="http://privacy.yahoo.co.jp/w3c/p3p_jp.xml";, CP="CAO DSP COR 
CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi 
IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
< Cache-Control: private, no-cache, no-store, must-revalidate
< Expires: -1
< Pragma: no-cache
< X-XRDS-Location: https://open.login.yahooapis.jp/openid20/www.yahoo.co.jp/xrds
< Vary: Accept-Encoding
< Content-Encoding: gzip
< Age: 0
< Proxy-Connection: keep-alive
<
{ [data not shown]
* Connection #0 to host localhost left intact
* Closing connection #0
{noformat}

> Allow POST requests without a Content-Length header
> ---------------------------------------------------
>
>                 Key: TS-2902
>                 URL: https://issues.apache.org/jira/browse/TS-2902
>             Project: Traffic Server
>          Issue Type: Improvement
>            Reporter: Masakazu Kitajo
>            Assignee: Bryan Call
>              Labels: review
>             Fix For: 5.1.0
>
>         Attachments: make_it_configuarable.patch
>
>
> I get "*400* Content Length Required" when user agents send a POST request 
> that doesn't contain any body data without a Content-Length header.
> (The header is omitted because the length is zero, I think)
> According to RFC2730 Section 3.3.2, presence of Content-Length is not MUST.
> http://tools.ietf.org/html/rfc7230#section-3.3.2
> {quote}
> A user agent SHOULD send a Content-Length in a request message when
>    no Transfer-Encoding is sent and the request method defines a meaning
>    for an enclosed payload body.
> {quote}
> Also according to section 3.3.3,  a server are allowed to reject similar 
> request with 411 Length Required, but not *400*.
> http://tools.ietf.org/html/rfc7230#section-3.3.2
> {quote}
>   A server MAY reject a request that contains a message body but not a
>    Content-Length by responding with 411 (Length Required).
> {quote}
> Traffic Server should accept the requests, no body data without 
> Content-Length header, or reject it with *411*. I think the former one is 
> better for interoperability.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to