[EventSource] Is Last-Event-ID header value allowed to contain any-char?

[yutakahirano]

A Last-Event-ID header value is set to the last event ID string which can contain any chars except CR and LF. On the other hand, the Fetch spec requires that a header value consists of field-content octets. The former allows non-CRLF control octets while the latter doesn't.

[yutakahirano]

cc: @annevk

[annevk]

See also whatwg/fetch#115. I'm happy to align this with whatever implementations implement. @hiroshige-g did not get back to me on that yet.

[yutakahirano]

Chrome:

• When the ID contains "\f", the reconnection request contains a Last-Event-ID header with the received ID.
• When the ID contains "\0", the reconnection request contains a Last-Event-ID header with a trimmed value (e.g. If "abc\0def" was received, "abc" will be sent).

Firefox:

• When the ID contains "\f", the reconnection request contains a Last-Event-ID header with the received ID.
• When the ID contains "\0", the reconnection request doesn't contain a Last-Event-ID header.

[yutakahirano]

I would like to ignore an ID value including any control characters when parsing it.

[annevk]

Control being anything less than 0x20 or higher than 0x7E?

[annevk]

Ooh, seems like the specification allows for non-ASCII values.

[yutakahirano]

The EventSource spec allows any octet composing a valid utf-8 string other than \r and \n while the HTTP spec allows only us-ascii printable chars (VCHAR).

[annevk]

You preference would be that we require VCHAR in the specification instead and ignore anything outside?

[annevk]

@wanderview, do you know who to ask from Mozilla about this?

[yutakahirano]

Both are acceptable, but I'm leaning towards ignoring an id field containing non-VCHARs. It looks consistent with the fact that we ignore an invalid retry field and other unrecognized fields.

[overholt]

@mcmanus can probably comment from Mozilla's standpoint.

[annevk]

@yutakahirano given what we decided for https://fetch.spec.whatwg.org/#concept-header-value I think UTF-8 bytes except for 0x00, 0x0A, and 0x0D is the way to go. Let me know if you disagree.

[yutakahirano]

Does it mean Firefox's behavior in #689 (comment)?

[annevk]

Yeah, ignoring altogether if it doesn't meet the criteria seems best. Dropping part of the value seems more dangerous.

[yutakahirano]

SGTM

[annevk]

@yutakahirano I think it would be even better if we didn't set evt.lastEventId at all if the id field contained U+0000. It does seem however that current implementation do include it and I also cannot reproduce your Chrome behavior (it does not appear to trim the value). See web-platform-tests/wpt#6584 for my test.

[annevk]

(It's also odd that browsers do not have the U+0000 restriction on header values here while they do have that in other APIs...)

[annevk]

#2849 has my proposal for how to change the HTML Standard. It would require changes by all implementations though, so feedback appreciated.