- From: Phil Hunt <phil.hunt@oracle.com>
- Date: Sun, 20 Jul 2014 13:31:15 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
There is a broader issue of how to handle queries in HTTP... Do as a separate header against any http method as suggested? Or... Do as a new http method eg QUERY to reduce overloading of POST and other methods. A big security issue is how to keep sensitive information out of URLs. I am not sure about the appropriate solution but I am interested in discussion to find a better one. Phil > On Jul 20, 2014, at 12:50, Mark Nottingham <mnot@mnot.net> wrote: > > <https://github.com/http2/http2-spec/issues/556> > > I’m not hearing anyone else express interest in this. > > Comments? Unless there’s a clamour of support soon, I’m inclined to close with no action. > > Cheers, > > >> On 12 Jul 2014, at 3:19 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> >> Some time ago I proposed and argued that :query should be split out >> from :path and as I perceived it, there were a lot of people nodding >> on that. >> >> I don't want to inject it right now, we have plenty of balls in the >> air, but can I get you top open an issue for it, so we don't forget ? >> >> (Some of) the arguments for :query: >> >> Load balancers and other "triage" proxies seldom if ever >> look at the :query part to determine handling, splitting >> this field out of :path means they don't have as much data >> to run through the decompressor to make their decisions. >> >> Semantically :path is much more static than :query is, which >> means that :path can be compressed by back-reference, whereas >> :query almost always will need huffman coding. >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk@FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. > > -- > Mark Nottingham http://www.mnot.net/ > > > >
Received on Sunday, 20 July 2014 20:31:58 UTC