On Mon, Feb 23, 2009 at 7:10 AM, Adam Barth <w...@adambarth.com> wrote: > On Sun, Feb 22, 2009 at 6:14 PM, Mark Nottingham <m...@mnot.net> wrote: >> A common use case (we think) will be to have >> <http://www.us.example.com/host-meta> HTTP redirect to >> <http://www.hq.example.com/host-meta>, or some other URI that's not on the >> same origin (as you defined it). > > What behavior do you think is desirable here? From a security point > of view, I would expect the host-meta from http://www.hq.example.com > to apply to http://www.hq.example.com (and not to > http://www.us.example.com).
I don't see why - if www.us.example.com chooses to delegate to www.hq.example.com, that that is its affair, not ours, surely? It does complicate matters if you are expecting host-meta to be signed, though. > >> I think that the disconnect here is that your use case for 'origin' and this >> one -- while similar in many ways -- differ in this one, for good reasons. > > I don't understand this comment. In draft-abarth-origin, we need to > compute the origin of a HTTP request. In this draft, we're interested > in computing the origin of an HTTP response. > >> As such, I'm wondering whether or not it's useful to use the term 'origin' >> in this draft -- potentially going as far as renaming it (again!) to >> /origin-meta, although Eran is a bit concerned about confusing early >> adopters (with good cause, I think). > > I don't have strong feelings about naming, but I wouldn't call it > origin-meta because different applications of the file might have > different (i.e., non-origin) scopes. > > Adam > >
