On Mon, 19 Nov 2007 23:55:26 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
I don't plan to change the cited text -- it doesn't have the problem I
mentioned (it's all in the present progressive). You didn't use the exact
same text, the problem was introduced in your changes.
I see. Tried to fix it.
Why is the "*." bit redundant in the domain part? How do I make sure
something matches "livejournal.com" but not
"ianhickson.livejournal.com"?
allow <livejournal.com> exclude <ianhickson.livejournal.com>
or more generic
allow <livejournal.com> exclude <*.livejournal.com>
Hm. Ok. I'm pretty sure this is confusing enough that it'll be the source
of security holes in future, though.
There is a scenario where you allow example.org and then later example.org
gives away subdomains to random users without considering the impact. But
there's also the problem Jonas mentioned. I'm not sure what we should give
precedence.
Does
allow <*.livejournal.com> exclude <livejournal.com>
...exclude everything in livejournal.com? (It seems that it does.)
Yes.
2.4. Referer-Root (sic) HTTP header: Do we need to continue
misspelling this?
It seems more consistent with the existing header.
Sure, but it's inconsistent with document.referrer, rel=noreferrer, and
the English word "referrer".
When making a script on the server rel=noreferrer and document.referrer
are not really relevant and Referer is. If other people feel strongly
about this too though than I'm willing to change it, but I rather not at
this point.
3.1. Cross-site Access Request: Does the referrer root URI include the
port even if it is the default port?
That's what the definition says, no?
I guess so. Why?
Consistency.
> 3.1. Cross-site Access Request: what does "Specifications are strongly
> encouraged to define this in equivalent ways." mean?
I reworded this. The intention is that specifications base it on the
same "source" as much as possible.
I still don't really understand what that means I should do, as a spec
editor.
Removed. The idea is that if you have a feature like
HTMLImageElement.getImageData() and also SVGImageElement.getImageData()
which depend on a cross-site GET access request for that functionality in
case of non same-origin URIs they both use the same "source" by having the
SVG and HTML people coordinate for instance.
3.1.1. Generic Cross-site Access Request Algorithms: What does
"transparently follow the redirect while observing the set of request
rules" mean?
It somehow needs to point back to the algorithm that invoked it where
there is a list of "request rules" which define what to do in case of a
network error, redirect, etc.
I don't think the spec is clear enough on this point at the moment. I'm
not sure I'd know what to do, as an implementor.
I tried making it more clear by having <i>request rules</i> marked up in
all instances.
Well, for variables I recommend <var>. For specific terms, <dfn> and <i>.
For keywords, <b>. For normal terms, nothing.
What to use for return values or values of flags?
Using current request URI is fine, but it needs to be clearer in the spec
what's going on. e.g. have some note somewhere in the main algorithm
pointing out the possible side-effects of the steps defined in the other
section.
Done.
I'm assuming this is related to the "macro" steps in "3.1.1. Generic
Cross-site Access Request Algorithms", but it isn't clear to me how
this all works. For example, those refer to "origin" but I don't know
what origin that is.
That's defined at the start of the algorithm that invokes it. It's the
referrer root URI.
The way the steps are factored out as actual steps that you substitute
in, rather than as a separate algorithm that you invoke, is a little
confusing, IMHO. I couldn't tell the "scope" of the "variables" (to use
programming terms). I think I understand what the spec is trying to say
now but it could probably be written more clearly (though I'm not sure
exactly how). Sorry to be so vague in my complaints!
I added a paragraph at the start of the generic thingie explaining where
the variables are coming from.
Actually, the idea *was* that the PUT would simply not be allowed. Error
flag to "fail" and "detail" to "network". I guess we should revisit
that. See below.
Yeah I don't think it would make sense for it to fail. You can just
imagine someone doing:
[...] Certainly if it didn't work it'd be very confusing.
Fixed.
Incidentally, you should mention whether the authorization request
cache can have multiple items with the same key. (It seems that it
can.)
The idea is that you can't. When would this be possible?
In the example above, the way the algorithm is currently defined, it is
possible for two items to be added with the same key (but with different
expires headers and methods). The spec doesn't say what should happen if
you add an item when there is already an item.
I now defined it in such a way that you can't have duplicates. Expired
entries are removed "automatically" and if there's a key match for a
non-expired entry, but no method match the entry is simply removed and a
new authorization request is done.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
