[whatwg] Specify href target with HTTP headers

Thanks for commenting on my suggestion.

Bjartur Thorlacius wrote on 2012-03-07 23:53:
> We should describe the security implications of lifting said
> restrictions (if any) in the rationale document, for when someone is
> burdened by these restrictions and can't figure if they were added
> for erring on the side of security or to address some specific
> security problems.
Yes, this needs to be elaborated.

I think it makes sense to follow the rules in section 5.1.6 of the HTML5 
spec:
http://dev.w3.org/html5/spec/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name


The rationale is that specifying "Window-Target: foo" for an HTML page 
has an effect similar to inserting "window.open(location.href, 'foo')" 
at the top of the page, so it should be subject to the same restrictions 
WRT navigating other browsing contexts.


> Content-Disposition seems like the "correct" header to use to me, but
> using the previously implemented header is fair enough.
> Window-Target and Content-Disposition must not appear in the same
> message, as the semantics of the former are a subset of the semantics
> of the latter AFAICT.
AFAIK no modern browser implements Window-Target, so I don't think the
we need to reuse the old header name. Expanding Content-Disposition is
also an option, e.g. "Content-Disposition: inline; target=_blank".
Unfortunately we cannot use "Content-Disposition: _blank", because
unknown values (not "attachment" or "inline") are treated as
"attachment" (RFC 2183, section 2.8).


> Separating the network protocol from the user interface seems highly
> desirable. Window-Target sacrifices that.
I get your point. But it seems that Content-Disposition already suffers
from this.

RFC 2183 describes the Content-Disposition like this:

   A mechanism is needed to allow the sender to transmit this sort of
   presentational information to the recipient; the Content-Disposition
   header provides this mechanism, allowing each component of a message
   to be tagged with an indication of its desired presentation semantics.

I know that RFC 2183 deals with e-mail and is not pat of HTTP/1.1, but
it is mentioned in the HTTP specification and is supported by several
browsers.


> Would it not be more appropriate to return an error response
> clearly marked as such? That, however, would leave the issue of
> connecting error messages to specific form fields.
That would sacrifice the ability to show error messages, help texts in 
the same way as on other forms (if I understand you correctly). Of 
course you can make some AJAX foo, but this easily gets complicated.


>> On <a> and <form> elements you can specify a target attribute, e.g.
>> _blank. But sometimes you don't know whether to open in _self or
>> _blank at the time the link is clicked/the form is submitted.
>
> The questions are, what information is necessary to decide whether to
> reuse the browsing context or not, and what other decisions depend
> on the said information?
It may depend on something external, e.g. the submitted form values 
(e.g. username and password) compared against an external database, so 
it cannot be determined without actually submitting the form.


-- 
Christian Schmidt

Received on Thursday, 8 March 2012 11:25:14 UTC