W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Question about RFC7540 (HTTP/2) section 10.5.1

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 7 Apr 2018 14:34:41 +0900
Message-ID: <CANatvzw0WSVzSdz8V4XVgRtNtKrN4xv6_4k7KwrxbjA1_OtGOw@mail.gmail.com>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: 安福一樹 <kazuki_yasufuku@dwango.co.jp>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
2018-04-07 0:29 GMT+09:00 Lucas Pardue <Lucas.Pardue@bbc.co.uk>:
> Hi,
>
>
>
> IMO from reading the specs, both RFC 7540 and 7230 apply. 7230 talks about
> individual header fields (and sets), while 7540 talks about the header block
> (the serialized combination of all header fields for a particular message).

I share the same view.

A H2 server can buffer the HEADERS frame and the following
CONTINUATIONS frames until it sees the END_HEADERS flag, and then try
to decode the frames at once. If the headers block is too large, the
server immediately sends a GOAWAY with ENHANCE_YOUR_CALM without
decoding HPACK.

We cannot have that kind of implementation if the specification
mandated the use of 431, because you cannot tell if the size of the
header fields were actually exceeding the limit without decoding
HPACK.

>
>
>
> FWIW it sounds like an implementation/config issue to me. What is the size
> of SETTINGS_MAX_HEADER_LIST_SIZE for these connections? It seems like that
> size is smaller than the check in your HTTP/1.1 case.
>
>
>
> I’m inclined to think that it is valid for a server to first send a 4XX
> response, followed by a GOAWAY with ENHANCE_YOUR_CALM. I’d be interested to
> hear what others think.

I would argue that there's no merit in sending a H2 level error (i.e.
ENHANCE_YOUR_CALM) in case you send a HTTP-level error (i.e. 4xx).

>
>
>
> Regards
>
> Lucas
>
>
>
> From: 安福一樹 [mailto:kazuki_yasufuku@dwango.co.jp]
> Sent: 06 April 2018 07:58
> To: ietf-http-wg@w3.org
> Subject: Question about RFC7540 (HTTP/2) section 10.5.1
>
>
>
> Hello
>
>
>
> I am a developer of this HTML5 game upload site
> https://game.nicovideo.jp/atsumaru/
>
> I have some question about RFC7540 section 10.5.1.
>
> Why server "CAN" send an HTTP 431 status code when receives a larger header
> block (not MUST)?
>
>
>
> In http/1.1 connection, server MUST respond 4xx status code when receives a
> larger header.(RFC7230)
>
> So, if user access a site that can upload any javascript code, and get large
> cookies, then we can send customized HTTP 4xx response which contains
> erasing cookie code.
>
> But, in http/2, server does not need to send HTTP 431 response, we will not
> have a chance to erase cookies.
>
>
>
> In actual implementaion, nginx will terminate http/2 session with
> ENHANCE_YOUR_CALM error without any HTTP responses, so chrome will display
> "cannot connect to server",
>
> So, we cannot send response which contains erasing cookie code to user who
> plays a game contains "Cookie Bomb".
>
>
>
> So, we have two questions.
>
> first question: why changed the text from "CAN" to "MUST" when recieves a
> large cookies(headers).
>
> second question: is this problem an implementation issue or a specification
> problem?
>
>
>
> Sincerely,
>
>
>
> Kazuki Yasufuku
>
>
>
> --
>
> *******************************************
>
> Kazuki Yasufuku
>
> Software Engeneer, UGC game platform section
>
> DWANGO Co., Ltd.
>
> E-MAIL:kazuki_yasufuku@dwango.co.jp
>
> *******************************************
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance
> on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------



-- 
Kazuho Oku
Received on Saturday, 7 April 2018 05:35:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC