- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Tue, 1 Nov 2016 07:14:05 +0200 (EET)
- To: Mark Nottingham <mnot@mnot.net>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Mark Nottingham <mnot@mnot.net>: (Tue Nov 1 00:41:56 2016) > Hold on -- are we layering in a new requirement to use the absolute form of the URL? > > That's going to cause issues with a number of client and server side implementations that don't have control over or access to the precise form of the URL on the wire. My original text suggestion was https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0097.html | When client send "http" requests over a TLS connection request | request MUST include scheme. This means that when used with | protocol identifier "http/1.1" (TTP/1.1 over TLS), request uses | absoluteURI -form. That is somewhat indirect requirement ☺ > It also violates a MUST in 7230, 5.3.1: > > """ > When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. > """ > > Cheers, Then net result mey be that do not use "http/1.1" but request need to be include scheme anyway. > > ( Seems that "Host" header is required also when absolute form is used. > > That I missed last time > > https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0097.html > > ) / Kari Hurtta > > > > -- > Mark Nottingham https://www.mnot.net/ >
Received on Tuesday, 1 November 2016 05:14:45 UTC