[whatwg] Specify href target with HTTP headers
Bjartur Thorlacius
svartman95 at gmail.com
Wed Mar 7 14:53:14 PST 2012
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
More information about the whatwg
mailing list