Subject: Server Push Error Codes

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Aug 2016 14:26:47 +1000

RFC7540, Section 8.2.2 says:

> Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the promised response until after the promised stream has closed.

> If the client determines, for any reason, that it does not wish to receive the pushed response from the server or if the server takes too long to begin sending the promised response, the client can send a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code and referencing the pushed stream's identifier.

Unfortunately, this doesn't give the server much information about why the push was refused. 

A few folks have talked about defining error codes to give more context to the server has been discussed. Below are a few straw-man proposals for discussion.

# PUSH_IS_CACHED

* Name: PUSH_IS_CACHED
* Code: 0xNN
* Description: On a RST_STREAM sent on a pushed stream, indicates that the sender already had a fresh cached response, and did not need to update it.
* Specification: [this document]

# PUSH_UNAUTHORITATIVE

* Name: PUSH_UNAUTHORITATIVE
* Code: 0xNN
* Description: On a RST_STREAM sent on a pushed stream, indicates that the server is not considered authoritative for the origin of the pushed request.
* Specification: [this document]

Note that this would need to overrule the following requirement in RFC7540, Section 8.2:

> The server MUST include a value in the :authority pseudo-header field for which the server is authoritative (see Section 10.1). A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5.4.2) of type PROTOCOL_ERROR.

# PUSH_CONTENT_ENCODING_NOT_SUPPORTED

* Name: PUSH_CONTENT_ENCODING_NOT_SUPPORTED
* Code: 0xNN
* Description: On a RST_STREAM sent on a pushed stream, indicates that the content-coding of the response is not supported by the client.
* Specification: [this document]

Thoughts?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Aug 2016 15:30:28 +1000

These seem mostly reasonable.

> # PUSH_UNAUTHORITATIVE

We are looking to provide solutions that make this unnecessary (absent
outright errors), but I think that it's a good code to have.

> # PUSH_CONTENT_ENCODING_NOT_SUPPORTED

This seems like it could be overly specific.  PUSH_NOT_ACCEPTABLE
might be used to cover Accept as well as Accept-Encoding.  Unless you
want both.

For content-encoding, it seems unlikely that the server will get this
wrong.  The server might reasonably assume that the value for
Accept-Encoding is constant and it will usually be right.  If not,
read on.

For Accept, a server might get it wrong, but it is probably the case
that the right machinery for determining whether a response is
acceptable isn't engaged when the push arrives.  That usually requires
a bunch of other context.  The same applies if Accept-Encoding isn't
constant.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Aug 2016 15:39:53 +1000

> On 24 Aug 2016, at 3:30 PM, Martin Thomson <[email-masked]> wrote:
> 

Yeah, I'm thinking more for outright error cases; when a server is misconfigured or mis-implemented, to save the admin / dev from banging their head against the wall too much.

> might be used to cover Accept as well as Accept-Encoding.  Unless you

Possibly. I don't disagree with anything you say, it's just that error codes are pretty cheap, and the places that these are going to be useful are dark corner cases that are really atypical.

> Accept-Encoding is constant and it will usually be right.  If not,

Except when it's not. :)

> a bunch of other context.  The same applies if Accept-Encoding isn't

Yeah, I didn't see much value in providing CONTENT_TYPE_NOT_SUPPORTED for that reason.

More than anything with these, I'm interested in collecting stats on them, to see how prevalent these sorts of problems are. If they aren't used, that's good news.

Cheers,

---

From: Emily Shepherd <[email-masked]>
Date: Wed, 24 Aug 2016 10:04:20 +0100

>Possibly. I don't disagree with anything you say, it's just that error codes are pretty cheap, and the places that these are going to be useful are dark corner cases that are really atypical.

I agree. I can't see a reason being specific in error conditions could 
ever be a bad thing.

Emily

-- 
Emily Shepherd
Computer Science Graduate, MEng (Hons)
W: https://emilyshepherd.me/
M: +44(0)7575 721 231

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Aug 2016 20:08:38 +1000

On 24 August 2016 at 19:04, Emily Shepherd <[email-masked]> wrote:
> I agree. I can't see a reason being specific in error conditions could ever
> be a bad thing.

There were a few times in TLS when overly specific error reporting
created an oracle that could be used to break the protocol.  Though
maybe HTTP is safe from that.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 24 Aug 2016 11:58:58 -0400

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.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 24 Aug 2016 18:52:07 +0000

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:[email-masked]]
Sent: Wednesday, August 24, 2016 8:59 AM
To: Mark Nottingham <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
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.