- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Sat, 20 Jul 2013 16:35:46 +0900
- To: Tobie Langel <tobie@w3.org>
- CC: public-test-infra <public-test-infra@w3.org>, Richard Ishida <ishida@w3.org>, Anne van Kesteren <annevk@annevk.nl>, "Phillips, Addison" <addison@lab126.com>
On 2013/07/19 23:09, Tobie Langel wrote: > On Friday, July 19, 2013 at 8:18 AM, "Martin J. Dürst" wrote: >> There is certainly a downside with tying in with Apache, but whatever we >> use, we'll be tying in with something, either some specific server or >> some specific software of ours, or so. > > Yes. >> The possibility to just put the stuff on a server e.g. for testing in >> private before submitting tests looks important to me. > > It's important to everyone, but complex testing scenarios (like dealing with HTTP headers) require server-side code. There's nothing we can do against that. Yes. The way I'm putting the question is "do we want to use existing code (where available), or do we want to write all of this ourselves?", and please note that "write ourselves" means "write ourselves multiple times" if we assume that we want this to work on multiple kinds of servers. >> To serve headers >> from a custom .header (or whatever we call it) file, we have to define >> the exact semantics of that file (see discussion about >> adding/replacing/removing headers, and that has just started), and have >> to make sure they get implemented ("picked up by the server" is easier >> said than done). > > Mozilla has been able to do something similar, I don't know why we wouldn't. :) Of course it can be done. But it's additional work, and additional stuff to learn for those who need to use it. We'd better work on the tests themselves if possible. Of course, if Mozilla already has it, and it's available, maybe we can reuse it. >> Because the implementations will differ from server to server, we have >> to make sure the implementations match. But then we start to be in the >> business of testing servers, were we intended to test clients. > > I image this will be application-level code, so independent of the server. Application-level code isn't exactly independent of the server. It very much depends on what kind of code, and what kind of server. >> BTW, in Apache there is also the .asis format, which contains both >> headers and body. That would work for those cases where we want >> everything in a single file. See >> http://httpd.apache.org/docs/2.2/mod/mod_asis.html. The downside is that >> then you can't test on a local file system because the headers get in >> the way. The upside is that it's a very clear format, and works with >> very little settings on Apache, and for other servers, it shouldn't be >> too difficult to make it work (although I'm not familiar with any other >> server than Apache); it would definitely be easier on other servers than >> .htaccess, which includes structured syntax and configuration options >> for many different Apache modules that are most probably difficult to >> mirror on other servers. > > How would that work with binary files? If nothing else works, cat foo.headers foo.binary >foo.asis will do the job. Maybe it has to be cat foo.headers newline.txt foo.binary >foo.asis if the original foo.headers doesn't contain a trailing empty line that signals the boundary between headers and content. >> Another idea would be to use a restricted subset of .htaccess >> functionality, but that would mean we would have to define that, and we >> would also have to check it. > > Yes, that is indeed the other option. Anyway, I don't care too much about which direction we go, as long as we don't get too hung up in useless complications and not-invented-here syndrome. Regards, Martin.
Received on Saturday, 20 July 2013 07:38:06 UTC