RE: Server Push Error Codes

Agree on the specific tracking element.  Unauthoritative gets a little hazier when we start dealing with secondary certs, however.  As Mark/Martin have alluded to, you shouldn’t get into the situation where the server believes that the client trusts it for an authority but the client doesn’t.  But if it happens, you want a way to identify that it’s happening so you can start debugging why.  (I’ll note that the certificates draft doesn’t currently define any HTTP/2 error codes for “cert doesn’t match the requested name,” which is probably an oversight.  The closest is UNSUPPORTED_CERTIFICATE, saying that the certificate did not contain required extensions, which could include the name.)

From: Patrick McManus [mailto:mcmanus@ducksong.com]
Sent: Wednesday, August 24, 2016 8:59 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Server Push Error Codes

I'm not real enthusiastic about push_is_cached.. it specifically leaks a tracker. Admittedly its pretty easy to infer this anyway but I'd look harder at it before codifying
as for push_unauthoritative, that's already a protocol error. I'm not sure we need fine grained feedback to tune algorithms etc with.. you're just not allowed to do that so it should be rare. I'm not opposed though.
I would be interested in both CONTENT_TYPE_NOT_SUPPORTED _and_ CONTENT_ENCODING_NOT_SUPPORTED .. I think brotli and webp are the exemplars. CT could be hard to figure out, but might be worth special casing the obvious stuff.