Server Push Error Codes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Server Push Error Codes

Mark Nottingham-2
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/


Reply | Threaded
Open this post in threaded view
|

Re: Server Push Error Codes

Martin Thomson-3
These seem mostly reasonable.

On 24 August 2016 at 14:26, Mark Nottingham <[hidden email]> wrote:
> # 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.

Reply | Threaded
Open this post in threaded view
|

Re: Server Push Error Codes

Mark Nottingham-2

> On 24 Aug 2016, at 3:30 PM, Martin Thomson <[hidden email]> wrote:
>
> These seem mostly reasonable.
>
> On 24 August 2016 at 14:26, Mark Nottingham <[hidden email]> wrote:
>> # 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.

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.


>> # 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.

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.

> 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.

Except when it's not. :)

> 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.

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,


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


Reply | Threaded
Open this post in threaded view
|

Re: Server Push Error Codes

Emily Shepherd
On Wed, Aug 24, 2016 at 03:39:53PM +1000, Mark Nottingham wrote:
>>> # 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.
>
>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

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Server Push Error Codes

Martin Thomson-3
On 24 August 2016 at 19:04, Emily Shepherd <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Server Push Error Codes

Patrick McManus
In reply to this post by Mark Nottingham-2
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.