- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 2 Feb 2018 23:38:01 +1300
- To: ietf-http-wg@w3.org
On 01/02/18 19:32, Willy Tarreau wrote: > On Thu, Feb 01, 2018 at 12:43:53PM +1100, Martin Thomson wrote: >> The observation is correct. However, I'm not sure that this is the >> solution I would choose. I'm not sure, but I think that an empty >> header field would cause problems. > > Some intermediaries risk to drop it, considering that empty is equivalent > to absent. > Ah, HTTP2-Settings is a connection specific header anyway. Intermediaries are *required* to remove it when forwarding, by section 3.2.1 paragraph 4. So removal seems to be a non-problem. >> Maybe the right conclusion to draw >> here is that you have to include at least one setting if you use this >> header field. > > I just tried to see if "====" would be possible as an encoding for an > empty string, but at least the base64 utility I have here considers > that it's an invalid input, so I suspect that it's not widely accepted > to have an end tag at the beginning of a base64 string. Thus most > likely as you suggest, something needs to be sent. Maybe we should > recommend to pass one of the default settings in this case. > > Willy > IMO, empty field-value should be valid even if it technically is not now. It is semantically (and literally) equivalent to a SETTINGS frame with 0-byte payload. On the plus side it should be a no-brainer for implementations not to even attempt decoding a 0-byte string. (That said the Squid tools for now send a pre-computed blob with the default SETTINGS from the spec. Have not tried sending empty payload.) Amos
Received on Friday, 2 February 2018 10:38:39 UTC