Re: Simple Proposal for setting HTTP headers

On 2013-07-20 09:35, Martin J. Dürst wrote:
> 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.

What Mozilla already have is a custom HTTP server, written in 
Javascript, using XPCOM extensions, that understands ^headers^ files, 
allows full control over the HTTP response, and has features optimised 
for testing.

What we want, in the long term, is a custom HTTP server, written in 
Python, that understands ^headers^ files (or similar), allows full 
control over the HTTP response, and has features optimised for testing.

Pyhton is a requirement here because it is the only language that all 
browser vendors are willing to run on their test machines. Note that the 
typical setup for automated testing is not "install the server on a 
single machine", but "run a new instance of the server for every test 
run on hundreds or thousands of test devices covering a wide range of 
platforms and capabilities". That makes introducing new technologies 
into the mix very difficult.

Received on Saturday, 20 July 2013 08:56:58 UTC