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

Re: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Thu, 20 Oct 2016 22:41:03 +0300 (EEST)
Message-Id: <201610201941.u9KJf348013272@shell.siilo.fmi.fi>
To: Van Catha <vans554@gmail.com>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>, Kazuho Oku <kazuhooku@gmail.com>, Tom Bergan <tombergan@chromium.org>, Ilari Liusvaara <ilariliusvaara@welho.com>
Van Catha <vans554@gmail.com>: (Thu Oct 20 22:17:49 2016)
> >  4.3.1.  GET
> > https://tools.ietf.org/html/rfc7231#section-4.3.1
> >
> > |   A payload within a GET request message has no defined semantics;
> > |   sending a payload body on a GET request might cause some existing
> > |   implementations to reject the request.
> > |
> > |   The response to a GET request is cacheable; a cache MAY use it to
> > |   satisfy subsequent GET and HEAD requests unless otherwise indicated
> > |   by the Cache-Control header field (Section 5.2 of [RFC7234]).
> 
> > Changing of scheme does not change semantic of methods.
> 
> It seems that sending a Cache-Control header to indicate no caching would
> work then?

Semantic still does not match.

https://tools.ietf.org/html/rfc7231#section-4.3.1

| 4.3.1.  GET
| 
|    The GET method requests transfer of a current selected representation
|    for the target resource.  


RFC 6455 also used GET -method, but it was changing protocol because of Upgrade.

1.3.  Opening Handshake
https://tools.ietf.org/html/rfc6455#section-1.3

|        GET /chat HTTP/1.1
|        Host: server.example.com
|        Upgrade: websocket
|        Connection: Upgrade


> I thought that a middlebox cannot cache ANYTHING unless the response
> contains headers to allow caching.
> It seems the opposite, anything can be cached unless strictly told not to.

4.2.3.  Cacheable Methods
https://tools.ietf.org/html/rfc7231#section-4.2.3

|   Request methods can be defined as "cacheable" to indicate that
|   responses to them are allowed to be stored for future reuse; for
|   specific requirements see [RFC7234].  In general, safe methods that
|   do not depend on a current or authoritative response are defined as
|   cacheable; this specification defines GET, HEAD, and POST as
|   cacheable, although the overwhelming majority of cache
|   implementations only support GET and HEAD.

/ Kari Hurtta
Received on Thursday, 20 October 2016 19:41:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 October 2016 19:41:38 UTC