[whatwg] Specify href target with HTTP headers
Christian Schmidt
_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.
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.
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.
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.
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.
[1]
http://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_admin_paths/7
[2]
http://drupalcode.org/project/drupal.git/blob/HEAD:/core/modules/overlay/overlay-parent.js#l530
--
Christian Schmidt
Bjartur Thorlacius
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.
>
(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
Christian Schmidt
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
Bjartur Thorlacius
> 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.
>
attachment given a query of download=yes. Make note of the thread
discussing a Content-Disposition attribute of <A>. I argue that
putting user interface hints into a file transfer protocol does cause
problems. In special, having two identifiers for the same resource,
one for when the resource is to be navigated to in an existing
browsing context and another for when navigation to the resource
implies creation of a new browsing context, breaks identification.
> 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.
>
I don't know if my pie in the sky thought should be taken seriously,
but why would I want another copy of the form I just submitted? I just
want the error messages.
Julian Reschke
> ...
>> 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.
Content-Disposition for HTTP is defined in RFC 6266.
> ...
Best regards, Julian
Christian Schmidt
> I argue that putting user interface hints into a file transfer
> protocol does cause problems
<head> of the destination page, or is that just another way of doing the
same?
> In special, having two identifiers for the same resource, one for
> when the resource is to be navigated to in an existing browsing
> context and another for when navigation to the resource implies
> creation of a new browsing context, breaks identification.
It was not my suggestion to use to introduce more URLs. But a resource
that is designed to be used in an iframe context often does not make
sense to load in the entire browser window (pages loaded in an iframe
often do not contain navigation, header, footer etc.), so in practice I
think a resource is often somewhat “tailored” to a specific browsing
context.
> I don't know if my pie in the sky thought should be taken seriously,
> but why would I want another copy of the form I just submitted? I
> just want the error messages.
I'm not sure I understand what you mean. The usual way of doing
server-side validation of a form (e.g. a login form) is to submit it and
- in case the validation fails - to show the same form prefilled with
the same data but with red boxes around the invalid fields, error
messages, help texts, etc. Of course you can do this by submitting the
form via AJAX and then manipulate the DOM via JavaScript, but that is
complex.
--
Christian Schmidt
Bjartur Thorlacius
wrote:
> Bjartur Thorlacius skrev 2012-03-09 10:43:
>> I argue that putting user interface hints into a file transfer
>> protocol does cause problems
> Would it be better if the Window-Target was somehow specified in the
> <head> of the destination page, or is that just another way of doing the
> same?
>
>
>> In special, having two identifiers for the same resource, one for
>> when the resource is to be navigated to in an existing browsing
>> context and another for when navigation to the resource implies
>> creation of a new browsing context, breaks identification.
> It was not my suggestion to use to introduce more URLs. But a resource
> that is designed to be used in an iframe context often does not make
> sense to load in the entire browser window (pages loaded in an iframe
> often do not contain navigation, header, footer etc.), so in practice I
> think a resource is often somewhat “tailored” to a specific browsing
> context.
>
>
context already, Window-Target should not create any new problems. But do
note that the streamlined presentation you describe makes sense for both
projection and tiny viewports as well. In fact, link collections such as
Wikipedia's "toolbox" are resources in and of themselves that are often
embedded in pages (or included by proxies) to optimize out costly
round-trips. Optimizing for iframes is mostly about trimming
non-(main)-content.
(For the record, I hunt for made-for-iframes pages, such as the Facebook
chat pop-out, and load them in a dedicated window to avoid clutter. I
simply prefer UI that minimizes the amount of on-screen distractions.)
> I'm not sure I understand what you mean. The usual way of doing
> server-side validation of a form (e.g. a login form) is to submit it and
> - in case the validation fails - to show the same form prefilled with
> the same data but with red boxes around the invalid fields, error
> messages, help texts, etc. Of course you can do this by submitting the
> form via AJAX and then manipulate the DOM via JavaScript, but that is
> complex.
>
I agree with all of the above. I find it notable that user agents have not
standardized on and implemented a form submit and validation protocol that
every AJAX page reimplements already. The reason is probably because
implementing said protocol would probably be more difficult to implement
in user agents, and harder to style by servers for branding reasons.
While I find it notable, I do not volunteer to change this. It would most
likely not be worth the effort.
--
-,Bjartur
Boris Zbarsky
> Bjartur Thorlacius skrev 2012-03-09 10:43:
>> I argue that putting user interface hints into a file transfer
>> protocol does cause problems
> Would it be better if the Window-Target was somehow specified in the
> <head> of the destination page
That's pretty much impossible to implement, since you have to pick the
window to load into before running any scripts and hence before doing
any parsing.
-Boris