- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 15 Dec 1998 20:10:14 -0500 (EST)
- To: WAI GL <w3c-wai-gl@w3.org>
While Apache is the single most popular webserver there are many people using other systems. However there is, in HTML, the META HTTP-EQUIV construction, which effectively allows pages to specify their own headers. This can (usually) be successfully exploited in one of the situation where control is impossible - the use of a CD, disc, etc to provide a website. Because these are very cheap to produce (CD's can be produced for around USD$1 in bulk, and around USD$3 in very small quantities) and can be used to serve multimedia materials much faster than the web they represent an important part of the user base. --Charles McCathieNevile - mailto:charles@w3.org phone:(temporary) +1 (617) 258 8143 http://purl.oclc.org/net/charles W3C Web Accessibility Initiative - http://www.w3.org/WAI 545 Technology sq., Cambridge MA, USA On Tue, 15 Dec 1998, Chris Kreussling wrote: > While it may not be true of the majority of readers of this list, > I believe most authors have no control over their server settings. > They don't have their own domain name; they're hosted as a user > web under their web presence provider. They have neither the > authority, skills, nor inclination to modify server settings. Then on Tue, 15 Dec 1998, Alan J. Flavell wrote in reply: May I speak to this point? While that's true, in as much as content providers who are in that situation wouldn't be able to influence the global settings of the server, there may very well be, in practice, ways for them to influence what the server does with their own documents. I'm speaking specifically of the properties of the .htaccess file in Apache (the most popular server, as I understand it) or the equivalent on other servers. One contributor had already expressed the view that HTTP protocol offers some vital functionality, that can't be achieved by other means. I support that view. There are various possible reactions to that. One would be "oh, that's too arcane for page authors, and server providers won't help them with it, so let's try to do without that functionality entirely". Another would be "HTTP is a vital part of the operation of the WWW, let's try to educate page authors to know what they're entitled to expect, and raise the general level of awareness". At some threshold, providers would then get accustomed to page authors making reasonable demands, and the providers pointing them to the appropriate place in the documentation. I think you can see which kind of approach I tend to favour. I recall some occasions in the past where I've told a page author, via a usenet article, "try putting this in your .htaccess", and later getting a reply along the lines of "hey, that worked, and even my provider was surprised how easy it was once one knew what to do". Even if the author has neither the inclination nor the aptitude for doing this, it's the case that pages are increasingly published by authoring/publishing software. Already such publishing software is installing proprietary stuff at the server to perform this or that function. Can that software not also be programmed to apply best practices regarding configuration of the web server for appropriate HTTP responses? So I really think it would be a defeatist attitude to write off the idea of exploiting HTTP at this relatively early stage in the process, albeit one would need to respect that fact that some content providers might have difficulties in that area. As a postscript, it's intriguing to hear that more and more authors are getting the facility to provide their own CGI scripts - something that frankly would have me tearing my hair out when I see the sort of security exposures that inexperienced authors create, not just for themselves but indirectly for the whole server; and yet it seems they aren't allowed to tackle the simplest of tasks for enhancing their HTTP responses for simple pages. This is back-to-front from where I'm sitting. Hope that was useful; all the best
Received on Tuesday, 15 December 1998 20:10:15 UTC