Re: [widgets] ETags and Automatic updates
On Thu, Jul 3, 2008 at 3:34 PM, Julian Reschke [EMAIL PROTECTED] wrote: Marcos Caceres wrote: On Wed, Jul 2, 2008 at 10:17 PM, mike amundsen [EMAIL PROTECTED] wrote: Marcos: snip I'm sure it could be done. But how can this be done easily with Apache or IIS? /snip Since Apache and IIS are HTTP servers, you can use the HTTP Headers to send hash data. Using the ETag is the most common, but if you like, you can propose a new HTTP Header (X-Widget-Hash). I know I should be able to do to send HTTP headers, but the question is still *how*? I mean, for Apache, do I modify the .htaccess file? if so, what do I put in there? If I can get a web server to send a custom ETag or Widget-Hash easily enough, then the solution is doable so long as its also easy to replicate in IIS and on any other web server. *Sending* a custom etag is not sufficient; Apache needs to be aware of it, otherwise all the conditional HTTP stuff will stop working. Yeah, this is kinda what I'm getting at :) FWIW, if it comes down to having to introduce a custom HTTP header, then I definitely think we should dump this solution. What about Content-MD5? Not supported by IIS, AFAIK. In Apache, sure, but, as [1] states, Note that this can cause performance problems on your server since the message digest is computed on every request (the values are not cached). And [2] says It was a bit proof-of-content code I added to Apache, and was never designed to be used in a real web server [1] http://apache.active-venture.com/mod/core3.htm [2] http://mail-archives.apache.org/mod_mbox/httpd-dev/199708.mbox/[EMAIL PROTECTED] -- Marcos Caceres http://datadriven.com.au
Cross-Site Requests, Users, UI (and What We're Trying to Fix)
All, At the recent F2F discussions in Redmond covering XMLHttpRequest (Level 2) and Access Control, the question of user involvement came up more than once. This discussion raised issues about whether or not the user should be informed by a user interface mechanism in the browser that a cross-site request was taking place. In general, discussion about *notifying the user* is part of a larger discussion about enabling sites to exchange *user-private data* via browser-based APIs such as postMessage and XMLHttpRequest with Access Control. Within Mozilla, we had several discussions about private data exchanges and the pros and cons of a user notification mechanism. Opinions within Mozilla vary. Often, given the nature of our open community and open participation model, we have to agree to disagree. Some hold the opinion that obtaining private data through a cross-site transaction, even with a mitigation mechanism such as Access Control, creates security or privacy scenarios that are unfavorable to end users. These same parties hold that at the very least, the user should have a user interface mechanism to stop the transaction. Others, including myself, hold the opinion that it is better to fundamentally *improve* existing cross-site access mechanisms, which certainly do not inform the user today [1], and to encourage developers to use safer APIs to build applications that engage in cross-site transactions. Moreover, it is desirable to introduce a mechanism that allows for stricter script inclusion, including inline scripts and maintaining lists of domains that are safe to script scr= from [2]. The way forward might be to: 1. introduce new mechanisms to do what developers do already[1], but allow them to be done safer, and to 2. clean up unsafe legacy mechanisms[2] as best as possible. While user interface mechanisms may help to generally inform the user and customize their web experience (e.g. stopping third party Cookies, etc.), STOP | CONTINUE type messages affiliated with APIs such as XMLHttpRequest (with AC) may be misleading in this context, since sites that wish to exchange data can use any number of mechanisms[1] on the web today and not inform the user. Of course, it is generally good behavior for sites that store user-private data to have privacy policies and inform the user about any sharing with other sites. -- A* [1] A (Not Exhaustive) Listing of Cross Site Mechanisms: http://www.arunranga.com/articles/browser-cross-site.html [2] Straw Person Proposal for Site Security Policy: http://people.mozilla.com/~bsterne/site-security-policy/
ISSUE-34: What happens when one runs out of storage space when decompressing a widget? [Widgets]
ISSUE-34: What happens when one runs out of storage space when decompressing a widget? [Widgets] http://www.w3.org/2008/webapps/track/issues/ Raised by: Josh Soref On product: Widgets When extracting the file data from a file entry, there is a chance that the storage device may run out of space. How should a widget user agent respond?
ISSUE-35: SVG as an icon format. [Widgets]
ISSUE-35: SVG as an icon format. [Widgets] http://www.w3.org/2008/webapps/track/issues/ Raised by: Marcos Caceres On product: Widgets Unsure as to how SVG is going to work as an icon format in regards to interactivity (eg. input events, javascript, animation, network connections, etc)?
ISSUE-36: Is the file API going to be part of Widgets 1.0? [Widgets]
ISSUE-36: Is the file API going to be part of Widgets 1.0? [Widgets] http://www.w3.org/2008/webapps/track/issues/ Raised by: Marcos Caceres On product: Widgets A few months ago Opera proposed a fileIO API for standardization [1]. It was discussed that widgets could make use of this API. The issue remains how would this API be integrated into Widgets 1.0? Should it be a core API or an external API to which a widget can bind to? http://dev.w3.org/2006/webapi/fileio/fileIO.htm
Publishing Web IDL (née Language Bindings for DOM)
Hello WG. It has been about three months since the last WD of Language Bindings for DOM (now Web IDL) was published, so I think with the new name and various changes it would be good to publish again. You can see the list of changes since last publication here: http://dev.w3.org/2006/webapi/WebIDL/#changes Charles, barring any objections, could you put that question to the group? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
