Resent-Date: Thu, 20 Oct 2016 19:41:40 +0000
Resent-Message-Id: <E1bxJDg-0003d9-7o@frink.w3.org>
Message-Id: <201610201941.u9KJf348013272@shell.siilo.fmi.fi>
In-Reply-To: <CAG-EYCjJB4MAiqDiogxLTyNpCtWcCH68T3sfKfjWNi6W=39R2w@mail.gmail.com>
References: <CANatvzx0+6P8+SifWY=4uFJUZg5mTKsjEeQgn2=w+huPEa9kyQ@mail.gmail.com>
 <20161020093357.AB25113BFC@welho-filter2.welho.com>
 <CAG-EYCjJB4MAiqDiogxLTyNpCtWcCH68T3sfKfjWNi6W=39R2w@mail.gmail.com>
To: Van Catha <vans554@gmail.com>
Date: Thu, 20 Oct 2016 22:41:03 +0300 (EEST)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
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>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Received-SPF: none client-ip=193.166.223.36; envelope-from=hurtta@siilo.fmi.fi;
 helo=smtpVgate.fmi.fi
Subject: Re: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re:
 Draft HTTPbis Agenda For Seoul IETF 97)
Archived-At: <http://www.w3.org/mid/201610201941.u9KJf348013272@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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