W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Examining the 'no server modification' requirement

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Fri, 11 Jan 2008 10:33:12 +1100
Message-Id: <B8F607CD-811A-44DF-BE58-314C8BB9CAE3@yahoo-inc.com>
To: "WAF WG (public)" <public-appformats@w3.org>

I'd like to take a closer look at the 'no server modification'  
requirement, because the more that I look at it, the more I don't  
understand why it should drive the architecture here.

As I understand it, the motivation for this is where a publisher wants  
to make data available cross-site, but doesn't have access to the  
server except to upload files; they cannot modify server configuration.

Looking around at the current Web hosting landscape, this is a pretty  
small set of resources. Consider;
    - Almost every commodity Web hosting provider (e.g., pair.com,  
dreamhost, 1&1, etc.) allows shell access and .htaccess modifications  
for mod_rewrite, as well as scripting, for a very small amount of money.
    - Those that don't offer shell access often still provide  
scripting (e.g., Perl, PHP). Both Moveable Type and Wordpress can be  
deployed using FTP only.
    - Even University accounts offer shell access (that's the point of  
a university account, after all), and usually offer .htaccess.

So, AFAICT, the only use case that really drives this requirement is  
for free shared hosting providers, a la GeoCities. It's not an  
adoption argument; as mentioned, MT and WP can both be deployed with  
just FTP, and their need to run an executable hasn't hindered  
deployment at all.

I'm struggling to imagine a situation where someone would want to host  
cross-site data on this type of site, being unable to do it elsewhere.  
What am I missing?

Also, from a policy standpoint, I do wonder if a site that doesn't  
allow modification of server configuration, shell access, etc. would  
want to allow cross-site requests to the things they host; AIUI most  
of these services spend considerable resources working to assure that  
their accounts aren't used for "bandwidth stealing" by already  
checking referers, etc.

Any illumination would be most appreciated.

Cheers,

--
Mark Nottingham       mnot@yahoo-inc.com
Received on Thursday, 10 January 2008 23:33:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC