Encode the Last-Event-ID header in EventSource as UTF-8.

Source/core/page/EventSource.cpp

Index: Source/core/page/EventSource.cpp
diff --git a/Source/core/page/EventSource.cpp b/Source/core/page/EventSource.cpp
index 2a6ff9cce0a2a1afaa3a9babd9b890714075472c..e1ba106fc0804cbfc1ceab52f34861032c9d577a 100644
--- a/Source/core/page/EventSource.cpp
+++ b/Source/core/page/EventSource.cpp
@@ -127,8 +127,11 @@ void EventSource::connect()
     request.setHTTPHeaderField("Accept", "text/event-stream");
     request.setHTTPHeaderField("Cache-Control", "no-cache");
     request.setRequestContext(blink::WebURLRequest::RequestContextEventSource);
-    if (!m_lastEventId.isEmpty())
-        request.setHTTPHeaderField("Last-Event-ID", m_lastEventId);
+    if (!m_lastEventId.isEmpty()) {
+        // HTTP headers are Latin-1 byte strings, but the Last-Event-ID header is encoded as UTF-8.
+        CString lastEventIdUtf8 = m_lastEventId.utf8();
+        request.setHTTPHeaderField("Last-Event-ID", AtomicString(reinterpret_cast<const LChar*>(lastEventIdUtf8.data()), lastEventIdUtf8.length()));

[Nate Chapin, 2015/01/06 18:23:34]

My WTFString-fu is not very good. Can you use AtomicString::fromUTF8() instead
of all this verbosity?

[davidben, 2015/01/06 19:30:34]

I don't think that work. This is an awkward thing where the type AtomicString is
arguably wrong for the API (it should be some variant of WTF::CString rather
than WTF::String).

Say m_lastEventId contains the UTF-16 string "\u2603" (with type uint16_t[]).
Encoded as UTF-8, that is the byte string "\xe2\x98\x83" (with type uint8_t[]),
so we want to send those three bytes on the wire.

All the way at the //net level, headers are just std::string, so we can easily
pass in a std::string containing those three bytes. From the entry point in
setHTTPHeaderField, all the way through to the Blink API boundary, headers are
AtomicString/WTF::String/WebString/etc. (Point is it's the Unicode-aware ones.)
They are then extracted as latin-1 or byte strings.

https://code.google.com/p/chromium/codesearch#chromium/src/content/child/web_...

That is, you assume every uint16_t UTF-16 code unit in the WebString is below
256 and get a std::string out of it as uint8_t's. (Let's ignore the silliness
where chars can be signed rather than unsigned.) I believe anything 256 or above
gets replaced as '?', but there really shouldn't anything above 256 at this
range. E.g. input to an XHR gets checked for invalid characters; this is a
WebIDL ByteString:
https://heycam.github.io/webidl/#idl-ByteString
https://xhr.spec.whatwg.org/#interface-xmlhttprequest

(And we can't defer the UTF-8 encode until it hits content/child and have
headers in Blink internally represented as true UTF-16 strings because
xhr.setRequestHeader may pass an input that's not the UTF-8 encoding of some
Unicode string.)


So, that's why this verbosity and the question of whether we should actually be
changing the types of setHTTPHeaderField. Then it might look like

  request.setHTTPHeaderField("Last-Event-ID", m_lastEventId.utf8());

and we'd have the type system check that every time data is converted from
WTF::String to/from a header, we make a decision about encodings. But I don't
know enough about Blink's string situation here. There doesn't seem to be an
AtomicCString.

+    }
 
     SecurityOrigin* origin = executionContext.securityOrigin();