Re: Request for advice

[Mark Nottingham <[e-mail]>]

Hi Paul,

> On 10 Feb 2016, at 11:14 pm, Paul Millar <[e-mail]> wrote:
> 
> Hi,
> 
> I am working within a small team devising a new HTTP-based protocol.  We hope to use a /.well-known URI and register this protocol with IANA.
> 
> The protocol involves the client issuing a POST request to the server and receiving some information back; i.e., this is not a lookup (GET or HEAD) request.
> 
> As I see it, there are two options:
> 
> a.	client issues POST requests directly to a well-known
> 	endpoint; e.g., /.well-known/<foo>
> 
> b.	client issues GET request to /.well-known/<foo-discovery>
> 	endpoint.  The response describes the location of <foo>.
> 	The client makes POST request to that URI.
> 
> Option a. has some advantages in terms of latency and reduced complexity; however, it seems from RFC 5785 that the latter option is more in line with the intended use of /.well-known.  Option b. is also the approach taken by most other registrants (e.g., OpenID-Configuration)
> 
> Would both approach be acceptable, or should we focus on option b. ?

(b) gives people who deploy more flexibility, in that they can direct clients to a different server, etc. This is especially helpful when you're expecting a POST, because if you want to redirect them, they'll have to retransmit the request body (unless both sides support expect/continue, which has proven problematic over the years).

It's true that this way requires an extra request, but the response can be cached. 

One question -- are you using a .well-known to enable someone to find out something about the host, or is it just a convenience? 

I.e., is it acceptable for your service to take a full URL as an input instead of a hostname? 

Cheers,


--
Mark Nottingham   https://www.mnot.net/