[whatwg] Specify href target with HTTP headers

On Wed, 07 Mar 2012 22:19:17 -0000, Christian Schmidt <whatwg.org at chsc.dk>  
wrote:
> I suggest that a server can specify a link target in an HTTP header,  
> e.g. "Window-Target: _blank". The page would be equivalent to specifying  
> the same value in the <form> or <a> tag leading to the page. It should  
> probably be subject to some kind of restrictions, e.g. the header could  
> be ignored if the link destination and the referring page had different  
> origins, unless the referring page specified some special value in the  
> target, e.g. _server (this value would indicate that the link  
> destination is a somewhat trusted resource whose Window-Target header  
> should be honoured). This ensures that the referring origin is always in  
> control of the target.
>
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.

> It seems there was such a header (to some extent, at least) back in  
> Netscape 4:
> http://lists.w3.org/Archives/Public/www-html/1998Jan/0010.html
> https://bugzilla.mozilla.org/show_bug.cgi?id=97459
>
> The Content-Disposition: attachment/inline header does something related  
> not entirely. Its was originally invented for use in MIME mails.
>
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.

>
> Use-case #1:
> Sometimes the form target cannot be determined until after the form has  
> been submitted. Assume you have a form of some kind. If the server-side  
> validation fails, you want to load the same page again (this time with  
> an error message) in the same window, but if the server-side validation  
> succeeds, you want to open a new window, e.g. containting a PDF or some  
> application-like window. This behaviour is sometimes done using  
> window.open() on the target page, but many popup blockers prevent this.
>
Separating the network protocol from the user interface seems highly  
desirable. Window-Target sacrifices that. 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.

> Use-case #2:
> In Drupal 8 the administrative pages are opened in an overlay/lightbox  
> on top of the frontend pages. For each URL it is specified (by means of  
> wildcard patterns in hook_admin_paths()) whether it should open in the  
> overlay or in the entire browser window, i.e. whether the URL is an  
> administrative page or not. For each link on a page the target attribute  
> should be specified accordingly (this is handled client-side using a  
> click handler on <a> elements that matches the current href against the  
> wildcard patterns and dynamically alters the target attribute - see  
> Drupal.overlay.eventhandlerOverrideLink in [2]). Contrary to use-case #1  
> it /is/ possible to preprocess all links, but it is a lot of work for  
> all links on a page. It would be easier if the server could determine,  
> whether the link that was actually clicked on should open in the overlay  
> or not.
>
Note that you can also annotate the links with target hints server-side  
when you serve the frontend pages. While Window-Target may not be a great  
solution to this problem, I can't think of a better one ATM.

> 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?

-- 
-,Bjartur

Received on Wednesday, 7 March 2012 14:53:14 UTC