Repository navigation
Reject response header blocks that don’t include the :status field #290
Description
Quoting from RFC 7540 section 8.1.2.4:
For HTTP/2 responses, a single
":status"pseudo-header field is
defined that carries the HTTP status code field (see [RFC7231],
Section 6). This pseudo-header field MUST be included in all
responses; otherwise, the response is malformed (Section 8.1.2.6).
This would mean adding another check in utilities.py to cover the possibility that this pseudo-header field is missing, and adding some new test cases in test_invalid_headers.py.
Activity
alexwlchan commentedon Aug 19, 2016
@Lukasa I’m not going to do this myself, because (1) I don’t have the time right now, and (2) I think this might be a good first patch for somebody else to take on.
But I did have a brief look at it, and I think we might want another field on
HeaderValidationFlags. Specifically – is this header block being sent or received?The sensible place (performance-wise) to do this check would be
_reject_pseudo_header_fields– we’ve already built up a set of pseudo-header field names, so we can just checkb':status' in seen_pseudo_header_fields, but I don’t think the current header validation flags give us enough information to know if this is a response or not.alexwlchan commentedon Aug 19, 2016
(Buttons, how do they work?!)
Lukasa commentedon Aug 20, 2016
Thanks for raising this up @alexwlchan! @python-hyper/contributors, if any of you feel like picking this up or have someone in mind who needs a good start in OSS, please assign the issue to yourself and tag the person you want to do the work. If not, I'll also go looking to find a new OSS contributor.
Lukasa commentedon Aug 30, 2016
Header validation should never strip a header. It may reject a header block (raise
ProtocolError), but never strip a header. Do you have a test case that shows this behaviour?As to in
HeaderValidationFlags, I think the flag we need is"is_response_header", which is set toTruewhen we're sending a response header block.Lukasa commentedon Aug 31, 2016
See my notes on the commit. =)
Lukasa commentedon Sep 6, 2016
Sure thing @aidylewis, that's no problem at all. This can go back on the pile. =)
sunu commentedon Sep 6, 2016
I can pick this up if it's okay.
Lukasa commentedon Sep 6, 2016
Fine by me!
Changelog for #290.
Lukasa commentedon Sep 20, 2016
Resolved by #311.