headers
Dan Connolly | 2 Jul 2007 18:45
Picon
Favicon

long HTTP header field name in WD-access-control


Yves,

We're discussing this "Enabling Read Access for Web Resources"
spec in a TAG telcon, and I discovered...

2.1. Content-Access-Control header
http://www.w3.org/TR/2007/WD-access-control-20070618/#content-access-control

Now as I recall, modern HTTP header fields are moving
from Transfer-Encoding: to TE: to save packets.
Can you confirm?

If so, I think Content-Access-Control should
be renamed ACL or some other 2 or 3 character name.

--

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Permalink | Reply | 5 comments |
headers
Yves Lafon | 2 Jul 2007 23:07
Picon
Favicon
Gravatar

Re: long HTTP header field name in WD-access-control


On Mon, 2 Jul 2007, Dan Connolly wrote:

> Yves,
>
> We're discussing this "Enabling Read Access for Web Resources"
> spec in a TAG telcon, and I discovered...
>
> 2.1. Content-Access-Control header
> http://www.w3.org/TR/2007/WD-access-control-20070618/#content-access-control
>
> Now as I recall, modern HTTP header fields are moving
> from Transfer-Encoding: to TE: to save packets.
> Can you confirm?

There is another reason to use TE: avoiding mixing the connection-level 
TE/Transfer-Encoding "couple" with the Accept-[Encoding|..] / 
Content-[Encoding|..]

That said, if you manage to have a shorter version of a long header while 
keeping the name obvious, it will be faster to parse. In the WD cited 
above, I would drop the 'Content'.

On a side note, I'm wondering why the WD states that the policy described 
is only safe for GET and HEAD... no OPTIONS?
Cheers,

--

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jonas Sicking | 4 Jul 2007 02:35
Gravatar

[ac] wildcard rules and subdomains


Hi All,

Currently the spec says that a rule like "*.example.com" does not match 
a request from example.com. The result is that if you want to give 
access to anything coming from example.com, including any subdomains, 
you'll have to write a rule like:

Content-Access-Control: allow <*.example.com>, <example.com>

And similarly, if you want to deny requests from evil.com you have to do:

Content-Access-Control: deny <*.evil.com>, <evil.com>

I think it would be better if *.example.com also matched example.com.

Pros:
In many cases you can write simpler rules since I'd imagine it's more 
likely that you want to deny or grant access to both a domain and its 
subdomains, than that you just want one of the two.

There's no longer a risk that someone will think that *.example.com does 
match example.com.

Cons:
There's a risk that someone will think that *.example.com does not match 
example.com.

I actually think that the consequences of misunderstanding is smaller in 
the latter case. Lets example the possible misunderstandings under the
(Continue reading)

Permalink | Reply | 11 comments |
headers
Mark Nottingham | 4 Jul 2007 03:58
Picon
Favicon

Re: [ac] wildcard rules and subdomains


IIRC (and I could be remembering wrongly), it was done this way to  
align with how p3p.xml, etc. work, so there wouldn't be multiple,  
almost-the-same-but-conflicting standards out there.

Cheers,

On 2007/07/04, at 10:35 AM, Jonas Sicking wrote:

>
> Hi All,
>
> Currently the spec says that a rule like "*.example.com" does not  
> match a request from example.com. The result is that if you want to  
> give access to anything coming from example.com, including any  
> subdomains, you'll have to write a rule like:
>
> Content-Access-Control: allow <*.example.com>, <example.com>
>
> And similarly, if you want to deny requests from evil.com you have  
> to do:
>
> Content-Access-Control: deny <*.evil.com>, <evil.com>
>
> I think it would be better if *.example.com also matched example.com.
>
> Pros:
> In many cases you can write simpler rules since I'd imagine it's  
> more likely that you want to deny or grant access to both a domain  
> and its subdomains, than that you just want one of the two.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jonas Sicking | 4 Jul 2007 04:45
Gravatar

Re: [ac] wildcard rules and subdomains


Ah, that makes sence. Though given the very poor uptake of p3p I don't 
think that parity with it is very important. I'd prefer to do what is 
safest and easiest to use.

/ Jonas

Mark Nottingham wrote:
> 
> IIRC (and I could be remembering wrongly), it was done this way to align 
> with how p3p.xml, etc. work, so there wouldn't be multiple, 
> almost-the-same-but-conflicting standards out there.
> 
> Cheers,
> 
> 
> On 2007/07/04, at 10:35 AM, Jonas Sicking wrote:
> 
>>
>> Hi All,
>>
>> Currently the spec says that a rule like "*.example.com" does not 
>> match a request from example.com. The result is that if you want to 
>> give access to anything coming from example.com, including any 
>> subdomains, you'll have to write a rule like:
>>
>> Content-Access-Control: allow <*.example.com>, <example.com>
>>
>> And similarly, if you want to deny requests from evil.com you have to do:
>>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Mark Nottingham | 4 Jul 2007 07:26
Picon
Favicon

Re: [ac] wildcard rules and subdomains


The P3P folks would disagree with your characterisation of uptake  
(e.g., <http://lorrie.cranor.org/pubs/icec06.pdf>). I'm staying out  
of it :)

On 2007/07/04, at 12:45 PM, Jonas Sicking wrote:

>
> Ah, that makes sence. Though given the very poor uptake of p3p I  
> don't think that parity with it is very important. I'd prefer to do  
> what is safest and easiest to use.
>
> / Jonas
>
> Mark Nottingham wrote:
>> IIRC (and I could be remembering wrongly), it was done this way to  
>> align with how p3p.xml, etc. work, so there wouldn't be multiple,  
>> almost-the-same-but-conflicting standards out there.
>> Cheers,
>> On 2007/07/04, at 10:35 AM, Jonas Sicking wrote:
>>>
>>> Hi All,
>>>
>>> Currently the spec says that a rule like "*.example.com" does not  
>>> match a request from example.com. The result is that if you want  
>>> to give access to anything coming from example.com, including any  
>>> subdomains, you'll have to write a rule like:
>>>
>>> Content-Access-Control: allow <*.example.com>, <example.com>
>>>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jonas Sicking | 6 Jul 2007 00:16
Gravatar

Re: [ac] wildcard rules and subdomains


I don't want to get into arguing about uptake either. A more important 
point is however that for the p3p spec err on the side of including 
fewer sites than expected is ok. The place where I see the syntax we're 
using is used is section 2.3.2.6 of the p3p 1.0 spec. If the author 
misses to add example.com in addition to *.example.com there will be no 
security issues.

This is not the case in our spec, if the author misses adding example.com to
Content-Access-Control: deny <*.evil.com>
very bad things can happen.

An alternative solution is to remove the wildcard syntax entierly, and 
say that it's implicitly always there. So

Content-Access-Control: deny <evil.com>, allow <good.com>

denies evil.com together with subdomains, while allowing good.com 
together with subdomains.

/ Jonas

Mark Nottingham wrote:
> 
> The P3P folks would disagree with your characterisation of uptake (e.g., 
> <http://lorrie.cranor.org/pubs/icec06.pdf>). I'm staying out of it :)
> 
> 
> On 2007/07/04, at 12:45 PM, Jonas Sicking wrote:
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Thomas Roessler | 6 Jul 2007 12:24
Picon
Favicon

Re: [ac] wildcard rules and subdomains


On 2007-07-05 15:16:34 -0700, Jonas Sicking wrote:

> This is not the case in our spec, if the author misses adding
> example.com to Content-Access-Control: deny <*.evil.com> very bad
> things can happen.

I guess that demonstrates why the deny tag isn't that good an idea
in the first place.

--

-- 
Thomas Roessler, W3C  <tlr <at> w3.org>
Permalink | Reply | 1 comment |
headers
Arthur Barstow | 6 Jul 2007 14:09
Picon

[ac] Comments from the TAG


One of the members of the W3C's Technical Architecture Group (TAG)  
submitted comments on the 18 June 2007 version of the Read Access  
document:

   <http://lists.w3.org/Archives/Public/www-tag/2007Jun/0145.html>

Regards,

Art Barstow
---
Permalink | Reply | 0 comments |
headers
Arthur Barstow | 6 Jul 2007 16:52
Picon

Re: Aligning grouping of resources in POWDER and WAF Access Control.


[[ ++ public-appformats - the mail list the WAF WG uses for its  
technical discussions ]]

Stuart - thanks for raising this issue. I have not discussed this  
issue with the WAF WG nor the WAF Public Community but here is *my*  
take on the syntax issue.

We discussed using regular expression syntax instead of just star. I  
recognize there would be some advantages to using the richer syntax  
but we decided to follow the KISS principle here, particularly given  
the negative side effects of incorrect syntax (e.g. accidentally  
giving access to a domain that should not have access). [I assume  
here the probability of incorrect syntax is higher with regular  
expressions than just star but I have no real data to back my  
assumption.]

It also appears our decision is consistent with the decision made in  
the P3P spec [1].

WAF WG & Community - please see the issue the TAG raises below.

Regards,

Art Barstow
---

[1] <http://www.w3.org/TR/P3P/#ref_file_wildcards>

On Jul 6, 2007, at 10:16 AM, ext Williams, Stuart (HP Labs, Bristol)
(Continue reading)

Permalink | Reply | 16 comments |

Gmane