Subject: Re: [httpwg/http-extensions] ORIGIN and Server Push (#355)

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 May 2017 00:27:07 -0700

_what the_ server _is able to push_, you mean?

Hmm, I would expect a server that sends out ORIGIN to have a positive idea what it is willing to serve on the connection. If it has no clear idea, it should probably refrain from ORIGIN?

If I understood correctly, the question boils down to: "Can the server, having send out ORIGIN, still PUSH resources from domains that are not in ORIGIN?"

And my answer would be no. I would like to use ORIGIN to hint to the client that on any other domain, it can expect a 421 as answer. The reason for that lies in separate TLS options for hosts that share a certificate. If those differ, the server should not server _or push_ resources from the other domain. It could require a client cert, or only stronger ciphers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-304796830

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 May 2017 00:41:38 -0700

@icing - the server doesn't know whether the client implements ORIGIN. It may have different PUSH strategies based upon ORIGIN support.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-304800011

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 May 2017 00:43:26 -0700

(It may be a corner case now, but if we open up the origin set a la CERTIFICATE, we'll hit this. That might be an argument for approach 1 - i.e., "we'll deal with it then.").

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-304800412

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 May 2017 00:43:46 -0700

It could, yes. But is that sane? Can ORIGIN require that the server answers requests outside of those domain the same way, no matter if the client understands it or not?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-304800482

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 May 2017 17:38:03 -0700

even in the absence of ORIGIN, the server does not know the client's effective origin set unless it is completely ignoring 7540 coalescing.. as mike bishop says we don't standardize pki decisions. istm its just a particular instance of a general push problem.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-305048179

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 May 2017 19:06:33 -0700

@mnot 
> (It may be a corner case now, but if we open up the origin set a la CERTIFICATE, we'll hit this. That might be an argument for approach 1 - i.e., "we'll deal with it then.").

My +1 goes to this.

When servers start sending secondary certificates to expand the authority (than that allowed by the names stored in the certificate sent during the TLS handshake), we would inevitably requiring the client to send a signal indicating if it accepted the certificate, which can be used as a signal.

Until then, I think that there is no need for an indication.

In fact, I think that it might be a good idea to clarify that the ORIGIN frame only changes what a _client_ is expected to request, and that it does not change what a server is allowed to push.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-305061503

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 31 May 2017 05:40:05 -0700

in the end, there are always going to be two different evaluations of the can-i-push rule and its going to be done on a per origin basis - once on the server and once on the client. This is just a generalization of the existing situation (and yet another example of the complexity of push). That's true of 7540 coalescing (e.g. client has a key pin rule that prohibits the coalescing the server doesn't know about), origin, and certificate.

I really think the RST_STREAM mechanism is sufficient - perhaps with a new error code made available for it.

This is an argument for 1.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355#issuecomment-305175554