Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt

[Bjartur Thorlacius <[e-mail]>]

On 5/30/11, Dzonatas Sol <[e-mail]> wrote:
> People often implement the ReSTful paradigm based only on these four
> http methods: POST, GET, PUT, DELETE. I hardly consider usage of those
> to the fullest means as any hack. (In my book. they each are subclasses
> of TASKs on the queue.)
>
I consider creating URIs under all URI authorities (as in the
authority section of the hierarchical part) questionable, not the
usage of an existing method. Why should the IETF construct URIs such
as <http://boards.4chan.org/.well-known/browser-hints> and
<URL:http://www.gov.cn/.well-known/browser-hints>. There's no image
board named ".well-known". It's /possible/ to use RFC 5785 for _all_
site-wide metadata, no matter what, just as it's /possible/ to use
POST to it's fullest, and POST exclusively, embedding the action and
entity-body in the message-body.
What queue? Most (but not all) HTTP methods operate on resources
identified by URIs.

> Any implication of an attacker... questionable on why would one stop
> there, specifically, even if we assume "they're inside".
>
You don't necessarily have to be "inside" to be able to upload files.
I'm thinking of a user registering as ".well-known" and uploading
maliciously named and crafted files. *All* HTTP servers out there will
have to reserve the "/.well-known" prefix, if only to avoid serving a
dangerous value of the max-conns property in the browser-hints file
(and thereby values of other properties such as max-pipeline-depth).

Note that I don't disagree with RFC 5785. It's the right mechanism for
certain tasks. I disagree with the apparent group consensus that
discovery of browser hints are one of these tasks.