Re: consensus on :query ?

It could make guessing things potentially easier.

In other words, this would need a security review.
On Jul 20, 2014 1:36 PM, "Phil Hunt" <phil.hunt@oracle.com> wrote:

> 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/
> >
> >
> >
> >
>
>