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

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