Currently, if we get any utf8 (non-ascii but valid utf8) character in http header values, during the header parsing they are converted to UChar (during the call of String::fromUTF8(const char*)) as opposed to LChar. This is wrong and fails use cases like
http://www1.w3c-test.org/webappsec/tests/cors/submitted/opera/staging/resources/cors-headers.php, which sends a header
X-Custom-Header-Bytes with valid UTF8 characters, but they are not rendered properly since they get converted to UChar. Firefox, Safari and IE do parse the header value correctly, but Chrome (as well as nightly WebKit/WebKit2 builds) fails to parse this header value correctly.
As far as my understanding of RFC2616, this is a valid case and we should support it. I intend to raise a bug for this and upload a CL to correct this. Please let me know if I am wrong or any other concerns.
Ravi Kasibhatla.