On 3/8/12, Christian Schmidt <whatwg....@chsc.dk> wrote: > 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. > Yes, it does. In fact servers often reply with Content-Disposition: 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.