You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Jan-Frode Myklebust <ja...@tanso.net> on 2013/12/12 13:43:34 UTC
IMS not propagating trough ATS
When sending an If-Modified-Since for an object that's not cached in
ATS, it doesn't seem like the IMS is propagated to the backend server,
so we're always getting 200/OK and full document sent to the client. Is
this known/expected behaviour, or a bug?
-jf
Re: IMS not propagating trough ATS
Posted by Yongming Zhao <mi...@gmail.com>.
sorry, mess up :D
in codes:
// we won't return NOT_MODIFIED if Last-modified not exists
if ((lm_value == 0) || (request->get_if_modified_since() < lm_value)) {
return response->status_get();
} else {
which controls if server do not response with a LM header, then IMS will be ignored. you can always check the cached request & response headers with the http_ui cache inspector.
FYI
Yongming Zhao
赵永明
aka 永豪 yonghao@taobao.com
在 2013年12月12日，下午10:19，Jan-Frode Myklebust <ja...@tanso.net> 写道：
> On Thu, Dec 12, 2013 at 09:31:08PM +0800, Yongming Zhao wrote:
>> that is a bug. in ATS, a missed range request must be passed to
>> the origin server, and not saved because the data is incomplete.
>
> It's not a range request.. We trigger it by running:
>
> curl -v -G --header 'If-Modified-Since: Tue, 11 Dec 2020 10:10:24 CET' https://www.example.com/ >/dev/null
>
> ------------------------------------------------------------------------------
> * About to connect() to apiint.services.example.com port 443
> * Trying 123.123.115.32... connected
> * Connected to apiint.services.example.com (123.123.115.32) port 443
> * successfully set certificate verify locations:
> * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> CApath: none
> * SSLv2, Client hello (1):
> SSLv3, TLS handshake, Server hello (2):
> SSLv3, TLS handshake, CERT (11):
> SSLv3, TLS handshake, Server finished (14):
> SSLv3, TLS handshake, Client key exchange (16):
> SSLv3, TLS change cipher, Client hello (1):
> SSLv3, TLS handshake, Finished (20):
> SSLv3, TLS change cipher, Client hello (1):
> SSLv3, TLS handshake, Finished (20):
> SSL connection using AES256-SHA
> * Server certificate:
> * subject: /OU=Domain Control Validated/CN=*.services.example.com
> * start date: 2013-07-16 11:49:36 GMT
> * expire date: 2016-09-07 17:12:44 GMT
> * subjectAltName: apiint.services.example.com matched
> * issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
> * SSL certificate verify ok.
>> GET /example/api/chill/chillAppConfiguration HTTP/1.1
>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>> Host: apiint.services.example.com
>> Accept: */*
>> If-Modified-Since: Tue, 11 Dec 2020 10:10:24 CET
>>
> < HTTP/1.1 200 OK
> < Date: Thu, 12 Dec 2013 14:16:45 GMT
> < X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
> < Content-Type: application/json
> < Access-Control-Allow-Origin: *
> < Access-Control-Allow-Methods: GET, POST
> < Access-Control-Allow-Headers: SessionTicket, Content-Type, Authorization
> < Vary: Accept,Accept-Language,Accept-Encoding
> < Age: 0
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Via: http/1.1 webedge4.lab.example.net (ApacheTrafficServer/4.1.2 [uIcMsSf pSeN:t cCMi p sS])
> < Server: ATS/4.1.2
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 100 6697 0 6697 0 0 143k 0 --:--:-- --:--:-- --:--:-- 6540k* Connection #0 to host apiint.services.example.com left intact
>
> * Closing connection #0
> * SSLv3, TLS alert, Client hello (1):
> ------------------------------------------------------------------------------
>
>>
>> if it is with V4.1.2 or master version, that is a new bug. if not,
>> that may be a fixed bug, it is known to broken in 3.2-3.3 releases.
>> if you can confirm that master tree have this issue, please file the
>> bug in the jira.
>
> It's v4.1.2-rc0. I'll open a jira ticket.
>
>
>
> -jf
Re: IMS not propagating trough ATS
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
On Thu, Dec 12, 2013 at 09:31:08PM +0800, Yongming Zhao wrote:
> that is a bug. in ATS, a missed range request must be passed to
> the origin server, and not saved because the data is incomplete.
It's not a range request.. We trigger it by running:
curl -v -G --header 'If-Modified-Since: Tue, 11 Dec 2020 10:10:24 CET' https://www.example.com/ >/dev/null
------------------------------------------------------------------------------
* About to connect() to apiint.services.example.com port 443
* Trying 123.123.115.32... connected
* Connected to apiint.services.example.com (123.123.115.32) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
* subject: /OU=Domain Control Validated/CN=*.services.example.com
* start date: 2013-07-16 11:49:36 GMT
* expire date: 2016-09-07 17:12:44 GMT
* subjectAltName: apiint.services.example.com matched
* issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
* SSL certificate verify ok.
> GET /example/api/chill/chillAppConfiguration HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: apiint.services.example.com
> Accept: */*
> If-Modified-Since: Tue, 11 Dec 2020 10:10:24 CET
>
< HTTP/1.1 200 OK
< Date: Thu, 12 Dec 2013 14:16:45 GMT
< X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
< Content-Type: application/json
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST
< Access-Control-Allow-Headers: SessionTicket, Content-Type, Authorization
< Vary: Accept,Accept-Language,Accept-Encoding
< Age: 0
< Transfer-Encoding: chunked
< Connection: keep-alive
< Via: http/1.1 webedge4.lab.example.net (ApacheTrafficServer/4.1.2 [uIcMsSf pSeN:t cCMi p sS])
< Server: ATS/4.1.2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6697 0 6697 0 0 143k 0 --:--:-- --:--:-- --:--:-- 6540k* Connection #0 to host apiint.services.example.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
------------------------------------------------------------------------------
>
> if it is with V4.1.2 or master version, that is a new bug. if not,
> that may be a fixed bug, it is known to broken in 3.2-3.3 releases.
> if you can confirm that master tree have this issue, please file the
> bug in the jira.
It's v4.1.2-rc0. I'll open a jira ticket.
-jf
Re: IMS not propagating trough ATS
Posted by Yongming Zhao <mi...@gmail.com>.
that is a bug. in ATS, a missed range request must be passed to the origin server, and not saved because the data is incomplete.
if it is with V4.1.2 or master version, that is a new bug. if not, that may be a fixed bug, it is known to broken in 3.2-3.3 releases. if you can confirm that master tree have this issue, please file the bug in the jira.
thanks
在 2013年12月12日，下午8:43，Jan-Frode Myklebust <ja...@tanso.net> 写道：
> When sending an If-Modified-Since for an object that's not cached in
> ATS, it doesn't seem like the IMS is propagated to the backend server,
> so we're always getting 200/OK and full document sent to the client. Is
> this known/expected behaviour, or a bug?
>
>
> -jf
Yongming Zhao
赵永明
aka 永豪 yonghao@taobao.com