Re: Simple Proposal for setting HTTP headers

On Jul 18, 2013, at 12:41 PM, Tobie Langel wrote:

> 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.

Except that requires you to specify the content-type. In the CSS test suites we often don't want to do that, especially as our build process converts HTML <-> XHTML and we serve our test suites in both formats... you want the server to determine the content-type based on the file extension, just override or not specify the charset sometimes.

>> 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.

It doesn't have to be anything especially sophisticated, you could still have per-file .headers files that are just a list of HTTP headers for the simple cases, and maybe something like a dir.headers file that lists file names (and/or maybe a regex) and headers (and it only need work in a single directory). 

Something like:
# simple file case
[foo.html]
Content-Type: text/html; charset=iso-8859-15
Set-Cookie: foo=bar

# regex case
{^bar(.)*\.html$}
Content-Type: text/html; charset=utf-8

--

(and allowing comments is always useful to document what's going on...)

> 
> TBH, I'd rather avoid having to deal with any of this until it really becomes an issue.

It _will_ be an issue for some of the CSS test suites.

>> 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?

Well you could always use the .header files for non-HTML files. The other option is that I already have the notion of side-car metadata files (<filename>.meta) for assigning metadata to non-HTML test and reference files (and/or HTML test files that can't contain the metadata for some reason, like it needs to not have a <head>). If we just consider the headers part of the metadata then it makes sense to put the headers there...

FWIW: the w3ctestlib Python library already has support for extracting metadata from test files... this would be trivial to add

Peter

Received on Friday, 19 July 2013 01:11:37 UTC