On Sat, Jun 25, 2011 at 11:17 AM, Blanc Gregory <[email protected]> wrote: > Hello, > > please find below a few spotted typos and comments. > > abstract: > "underlie" instead of "underly" > "concept of origin" instead of "origin concept"
Fixed. > page 5: > "an idna-canonicalized" instead of "a idna-canonicalized" Fixed. > page 9: > 3.4.1 > "content retrieved from one URI" instead of "content retrieve from one URI" Fixed. > page 10: > 3.4.2 > "permitted to use" instead of "permitted use" Fixed. > page 13: > 5. > "Two origins" instead of "To origins" Fixed. > page 16: > 7.2 > "For example, consider a user agent that executes scripts on behalf of > origins. If one of those scripts causes the user agent to issue an > HTTP request, the user agent might wish to use the Origin header to > inform the server that the request was issued by the script". > Since the Origin header is a list of serialized origins, we can > assume this contains the origin that issued the request but not > the specific script as the sentence above indicates. > This is somehow tackled in page 19, section 8.3. I've clarified that the Origin header indicates the security context in which the script was executing, not necessarily the origin of the script code itself. > "In some cases, a number of origins contribute to causing the user > agents to issue an HTTP request. In those cases, the user agent can > list all the origins in the Origin header. For example, if the HTTP > request was initially issued by one origin but then later redirected > by another origin, the user agent might wish to inform the server > that two origins were involved in causing the user agent to issue the > request". > Does the sentence above only refer to the case of redirection as > evidenced by the example or does the author implies other cases? There are other cases as well. For example, imagine a call stack that involves a bunch of origins. If you were interested in stack inspection, you might list all those origins in the Origin header. > To the best of my knowledge, I cannot think of any other case? > Maybe I should think more about it. At least, cases implied here > are only sequential and never concurrent, aren't they? I'm not sure there are any other concrete examples today, but there could well be in the future. The point is just to have the flexibility in case we need it in the future. Generally speaking, there are many causes for any particular event, so this syntax+semantics gives us the flexibility to handle that case, if we need it. Thanks! Adam > 06/25/11 に、Adam Barth <[email protected]> さんは書きました: > >> I've posted an updated version of the origin draft: >> >> http://www.ietf.org/id/draft-ietf-websec-origin-02.txt >> >> The new version includes Security Considerations, IANA Considerations, >> and a completed references section. Feedback on the new Security >> Considerations section would be much appreciated. >> >> I also removed the (stub) Privacy Considerations section. If there's >> something you think should be discussed there, let me know. >> >> Thanks, >> Adam >> _______________________________________________ >> websec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
