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

Re: Op-sec simplification

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Tue, 1 Nov 2016 07:14:05 +0200 (EET)
Message-Id: <201611010514.uA15E5bu009103@shell.siilo.fmi.fi>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 05:14:46 UTC