<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Validation in isValidHTTPHeaderValue is too sensitive."
href="https://bugs.webkit.org/show_bug.cgi?id=147445#c18">Comment # 18</a>
on <a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Validation in isValidHTTPHeaderValue is too sensitive."
href="https://bugs.webkit.org/show_bug.cgi?id=147445">bug 147445</a>
from <span class="vcard"><a class="email" href="mailto:youennf@gmail.com" title="youenn fablet <youennf@gmail.com>"> <span class="fn">youenn fablet</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=147445#c17">comment #17</a>)
<span class="quote">> > If we split the sub-issues, that would give:
> > 1. Add support for trimming whitespaces in XHR.setRequestHeader
>
> I'm not sure if that would be an observable change in behavior given the
> below...
>
> > 2. Ensure XHR can set a header with an empty value
>
> I think that this should raise an exception.</span >
Why should it be?
It is a valid value per the HTTP spec.
The semantics of that value is defined for some standardized headers, probably for application specific headers as well.
Firefox, Chrome and IE are not throwing.
<span class="quote">> > 3. Ensure XHR can set "Content-Type" with an empty value
>
> Ditto.</span >
This case is really less appealing.
But again, what is the benefit of throwing here?
The same throw/notthrow rule should apply to all settable headers.
Since there are defaulting rules defined for this header, the processing of a Content-Type empty header value might be defined differently though if that proves to be useful.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>