"Authoritative" restrictions

[mnot]

10.1 Server Authority and Same-Origin says:

A client MUST NOT use, in any way, resources provided by a server that is not authoritative for those resources.

This seems too restrictive; it disallows layering in Alt-Svc, for example (either in this process, or later on) without changing the ALPN identifier.

[martinthomson]

I'm not so certain. Alt-Svc or whatever future mechanism we use (POSH, attribute cert-based delegation...as if) is free to alter the meaning of "authoritative". I believe that this is what Alt-Svc actually does to a small extent.

[grmocg]

What Martin said.
It is important that a client never use anything not authoritative. If we
believe that there is a scenario that doesn't fit the current meaning of
authoritative, that is what should probably change.

On Wed, Feb 19, 2014 at 9:10 PM, Martin Thomson [email protected]:

I'm not so certain. Alt-Svc or whatever future mechanism we use (POSH,
attribute cert-based delegation...as if) is free to alter the meaning of
"authoritative". I believe that this is what Alt-Svc actually does to a
small extent.

Reply to this email directly or view it on GitHubhttps://github.com//issues/405#issuecomment-35589858
.

[mnot]

If we rewrite the definition of authoritative to allow it to be monkey-patched by future specs, I'm OK with that.

[martinthomson]

Let's make sure that we have a better definition of authoritative. That should include dropping the dependency on RFC 6454. The origin model is nice, but I don't think that it's adding anything here: http://http2.github.io/http2-spec/#authority

Also, there's a weaselly use of "generally" when describing what can be pushed: http://http2.github.io/http2-spec/#rfc.comment.2 If we get "authoritative" right, we should just use that.

[martinthomson]

So, I looked at this yesterday, and made some changes ^^. By my reading, the definition of "authority" in HTTP/1.1 suits our ends perfectly. I couldn't see any way that it could be interpreted that would disallow coalescing, which we all thought was the big feature we were adding here.

So what I've done is more explicitly reference the text in HTTP/1.1 p1. I haven't added explicit text regarding changes to this. I'm a little uncomfortable saying "Future specifications MAY change the definition of authoritative." Mostly because that seems too open to me. Getting any change right could be tricky. I don't want people thinking that they can arbitrarily monkey patch HTTP with their spec. That wouldn't be good for the protocol.

I think that we can easily write another RFC that "Updates" either HTTP/1.1 or HTTP/2 with respect to the definition of "authority".

[mnot]

Discussed in London; Martin to use HTTP/1 text.

[reschke]

The current HTTP/1.1 text: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-26.html#establishing.authority