- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 14 Apr 2010 11:57:15 -0700
- To: Arthur Barstow <Art.Barstow@nokia.com>
- Cc: ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Wed, Apr 14, 2010 at 11:20 AM, Tyler Close <tyler.close@gmail.com> wrote: > On Wed, Apr 14, 2010 at 9:41 AM, Tyler Close <tyler.close@gmail.com> wrote: >> I have been studying CORS ISSUE-90 >> <http://www.w3.org/2008/webapps/track/issues/90>, so as to bring UMP >> into line with this part of CORS. I can't find any pattern or >> rationale to the selection of headers on the whitelist versus those >> not on the whitelist. Does anyone know where this list came from and >> how it was produced? >> >> If I produce a more comprehensive whitelist for UMP will CORS follow my lead? > > The following whitelist includes all end-to-end response headers > defined by HTTP, unless there is a specific security risk: > > # Age > # Allow > # Cache-Control > # Content-Disposition > # Content-Encoding > # Content-Language > # Content-Length > # Content-Location > # Content-MD5 > # Content-Range > # Content-Type > # Date > # ETag > # Expires > # Last-Modified > # Location > # MIME-Version > # Pragma > # Retry-After > # Server > # Vary > # Warning > > Does anyone object to making this the new whitelist for both CORS and UMP? Alternatively, instead of drawing the line at the HTTP spec, we could draw it based on functionality. The following list includes all end-to-end response entity headers, as well as all headers used for caching and redirection: # Age # Cache-Control # Content-Encoding # Content-Language # Content-Location # Content-MD5 # Content-Type # Date # ETag # Expires # Last-Modified # Location # MIME-Version # Pragma # Vary # Warning CORS and UMP would then provide cross-origin access to response entities, not to responses. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 14 April 2010 18:58:32 UTC