Tyler Close wrote:
On Wed, May 12, 2010 at 12:33 PM, Nathan <nat...@webr3.org> wrote:
Yes,
The simplest argument I can give is that we (server admins) are trusted to
set the CORS headers, but not to remove any headers we don't want an XHR
request to see - this is frankly ridiculous.
The problem is there might not be a single server admin but many.
Quoting from the UMP spec:
"""
Some HTTP servers construct an HTTP response in multiple stages. In
such a deployment, an earlier stage might produce a uniform response
which is augmented with additional response headers by a later stage
that does not understand a uniform response header. This later stage
might add response headers with the expectation they will be protected
by the Same Origin Policy. The developer of the earlier stage might be
unable to update the program logic of the later stage. To accommodate
this deployment scenario, user-agents can filter out response headers
on behalf of the server before exposing a uniform response to the
requesting content.
"""
http://dev.w3.org/2006/waf/UMP/#response-header-filtering
I believe the design presented in UMP for response header filtering
addresses all use-cases, including your "Location" header example
below.
Yes that pretty much covers it, can you confirm if "Uniform-Headers"
would include the Link header as white-listed? That's the last remaining
crucial one not covered. (Link header is standards track now).
BTW: I will point out that I hadn't reviewed the UMP spec yet so thisn't
isn't any political or preference thing.
I still stand by my statement though, CORS cannot possible go through to
REC status without the headers whitelisted in UMP + the Link header.
Although my preference for both specs would be a Blacklist..
Best,
Nathan
--Tyler
CORS and same origin rules have already closed off the web and made *true*
client side applications almost impossible, in addition it's planned to
remove headers which are vital for many applications to work. Including many
headers that are vital to the way the web works and part of the HTTP spec
for very good reasons.
Can't happen, not good, no argument could ever change my opinion on this,
and it definitely needs changed.
http://tools.ietf.org/html/rfc5023#section-5.3
AtomPub 5.3: Creating a Resource
..If the Member Resource was created successfully, the server
responds with a status code of 201 and a *Location* header that
contains the IRI of the newly created Entry Resource.
You can't seriously block REST, the design of the web - this is ridiculous.
Nathan
Devdatta wrote:
IIRC HTTP-WG has asked this WG to change this behavior from a
whitelist to a blacklist. There was a huge discussion about this a
while back -- maybe this could be an example of why CORS should follow
the HTTP-WG's recommendations.
-devdatta
On 12 May 2010 11:50, Nathan <nat...@webr3.org> wrote:
All,
Serious concern this time, I've just noted that as per 6.1 Cross-Origin
Request of the CORS spec, User Agents must strip all response headers
other
than:
* Cache-Control
* Content-Language
* Content-Type
* Expires
* Last-Modified
* Pragma
This simply can't be, many other headers are needed
Link header is going to be heavily used (notably for Web Access Control!)
Allow is needed when there's a 405 response (use GET instead of POST)
Content-Location is needed to be able to show the user the real URI and
provide it for subsequent requests and bookmarks
Location is needed when a new resource has been created via POST (where a
redirect wouldn't happen).
Retry-After & Warning are needed for rather obvious reasons.
There are non rfc2616 headers on which functionality is often dependent
(DAV
headers for instance) - SPARQL Update also exposes via the MS-Author-via
header.
In short there are a whole host of reasons why many different headers are
needed (including many not listed here).
Nathan
