W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: HTTP response cacheability and query components

From: Sufian Rhazi <srhazi@imvu.com>
Date: Fri, 18 Oct 2013 10:11:42 -0700
Message-ID: <CAF=qRiT94ouSVmMVAcd1ZzEuHxDTyiassg6d7TPC4qCFtcMcQQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks a lot for these references, they address my concerns.

Cheers,
Sufian


On Fri, Oct 18, 2013 at 12:17 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-10-18 02:30, Zhong Yu wrote:
>
>> On Fri, Oct 18, 2013 at 7:37 AM, Sufian Rhazi <srhazi@imvu.com> wrote:
>>
>>> Hello,
>>>
>>> I was looking into some surprising behavior in Akami, where they ignored
>>> the
>>> query component of the requested resource's URI. A request to
>>> http://foo/bar?baz=2 resulted in a cached response to a previous request
>>> from http://foo/bar?baz=1. This struck me as unexpected, since browsers
>>> tend
>>> to cache responses with respect to the URI query component, and would
>>> break
>>> applications that expect to be able to use queries for pagination,
>>> filtering, etc...
>>>
>>> I found that RFC 2616 defines "Request-URI" as the abs_path component of
>>> the
>>>
>>
>> RFC 2616 doesn't even allow any "/bar?baz=1" request. The spec and the
>> practice are clearly out of sync. You should probably consult http bis
>> for a more up to date description of http protocol.
>>
>
> See <http://trac.tools.ietf.org/**wg/httpbis/trac/ticket/11<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/11>>.
> This has been of the somewhat official RFC 2616 errata list for something
> like a decade.
>
>  ...
>>
>
> Best regards, Julian
>
Received on Friday, 18 October 2013 17:12:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC