- From: Tobie Langel <tobie@w3.org>
- Date: Thu, 18 Jul 2013 21:41:56 +0200
- To: Peter Linss <peter.linss@hp.com>
- Cc: public-test-infra <public-test-infra@w3.org>, Richard Ishida <ishida@w3.org>, ""Martin J. Dürst"" <duerst@it.aoyama.ac.jp>, Anne van Kesteren <annevk@annevk.nl>, Phillips, Addison <addison@lab126.com>
Thanks for the feedback, Peter! On Thursday, July 18, 2013 at 6:58 PM, Peter Linss wrote: > A few concerns with this proposal though: > > 1) we need the ability to remove headers as well as add them (as is prevent default server behavior), at least for charset based on current use [1]. So we need some syntax to specify that. Overwriting the content-type header lets you do that already. > 2) we have a lot of cases where the same header is set for a large number of files in a directory. Having one header file per test file will cause a lot of extra files to be generated. Not a show stopper, but it might be nice to have the ability to specify a set of headers for multiple files in one place, especially for tests that have a set of related files I considered this. The downside is you have to depart from strict HTTP syntax to allow for per extensions directives, recursive dir handling, etc. TBH, I'd rather avoid having to deal with any of this until it really becomes an issue. > 3) having information necessary to execute a test properly in a separate file is generally a recipe for breakage. Another option might be to embed the header data inside the test file like we do for other metadata? Though this could be problematic for other file types like CSS and images… Yeah. Thought about that too. And came to the same conclusion as you did: how do you handle non HTML pages? --tobie
Received on Thursday, 18 July 2013 19:42:08 UTC