On Wed, 07 Mar 2012 22:19:17 -0000, Christian Schmidt <whatwg....@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
