Skip to content

It’s possible to send header blocks from hyper-as-server that hyper-as-client will reject #262

Description

@alexwlchan

Picking up a comment from #261:

We do a series of checks in the validate_headers pipeline for incoming header blocks, in particular:

  • All fields should be lowercase.
  • A Transfer-Encoding header must have value "trailers"
  • No blocks with the Connection header.
  • No duplicate pseudo-header fields and/or pseudo-header fields coming after an ordinary header field.
  • No header blocks with bad :authority/Host headers.

But we don’t enforce all these rules on header blocks that we send, which suggests that it’s possible to send a header block with hyper that we’d reject if we received. Which seems odd.

(1) is achieved by the _lowercase_header_names pipeline, and I’m adding (5) in #261. I think we should be enforcing (2)-(4) on header blocks that we send as well.

Does that seem sensible?

Activity

  1. Lukasa commented on Jul 21, 2016

    @Lukasa
    Member

    I think we should enforce those too. =)

  2. Lukasa commented on Jul 21, 2016

    @Lukasa
    Member

    I've updated the original comment to turn the list into a list of checkboxes so we can keep track. Feel free to tackle each one separately.

  3. alexwlchan commented on Aug 3, 2016

    @alexwlchan
    ContributorAuthor

    Note: if you’re going to tackle this, you should read the discussion on #246 about being able to skip these checks in certain cases.

  4. alexwlchan commented on Aug 30, 2016

    @alexwlchan
    ContributorAuthor

    All addressed in #289.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions