Maciej Stachowiak wrote:
Treating null as empty string here may be sensible (no strong opinion
either way) but removing the header when set to empty seems wrong. If
header removal is really essential we should add a method for it.
In HTTP, absence of a header is different from having an empty
Anne van Kesteren wrote:
Or are you claiming that people who set a header to null *really* want
the specified behaviour?
It's consistent with other JavaScript APIs were null also means "null".
Overloading this API to also do removal of the header is not a goal here
and is simply a bug in Fir
On May 25, 2008, at 3:19 PM, Anne van Kesteren wrote:
On Sun, 25 May 2008 18:04:14 +0200, Julian Reschke <[EMAIL PROTECTED]
> wrote:
Apparently existing content does not rely on it (FF gets away with
implementing something that IMHO makes *much* more sense). So why
standardize it at all,
On May 25, 2008, at 11:40 AM, Jonas Sicking wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke <[EMAIL PROTECTED]
> wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari
are conformant here. (n
On Sun, 25 May 2008 20:40:48 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Agreed. We have in the past said that in the cases where it doesn't seem
like the web is depending on a certain behavior one way or the other do
what is most useful. I don't really think it matters much if null is
On Sun, 25 May 2008 23:36:48 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
If the header is simply named 'Origin' (or 'Referer-Root') then blocking
any requests that include that header would also block for example
cross-site image requests or cross-site POSTs.
Right. Given that it's like
On Sun, 25 May 2008 18:04:14 +0200, Julian Reschke <[EMAIL PROTECTED]>
wrote:
Apparently existing content does not rely on it (FF gets away with
implementing something that IMHO makes *much* more sense). So why
standardize it at all, or, when doing so, select something that doesn't
make s
Anne van Kesteren wrote:
On Sat, 24 May 2008 10:32:03 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
On Tue, 13 May 2008 07:42:59 +0200, Adam Barth
<[EMAIL PROTECTED]> wrote:
One option is to rename the header "Sec-Origin", which is already
blocked in XHR Level 1.
True, but I think Ac
Further comments after attending a talk at an IEEE security workshop (where
Ian's proposal was presented to various security experts):
1) I take back my suggestion about considering versus
Ian's original . Ian's original approach, although
more restrictive, does start off from a foundation based
Julian Reschke wrote:
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke
<[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari are
conformant here. (null and undefined are simply stringified.)
Not terrib
Anne van Kesteren wrote:
I changed my mind on several things below.
On Fri, 16 May 2008 13:37:54 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
Anne, can you summarise what needs doing to XHR2 and AC to move the
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke
<[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari are
conformant here. (null and undefined are simply stringified.)
Not terrible useful, I would say.
12 matches
Mail list logo
