Re: Simple Proposal for setting HTTP headers

On 08/07/2013 03:05 AM, Robin Berjon wrote:
> On 07/08/2013 03:11 , James Graham wrote:
>> That sounds like a bad idea :) It introduces significant complexity
>> through a dependence on v8 and the glue code, merely to get javascript
>> rather than python.
>
> I knew you'd say that :)
>
>> Another option is to build atop the mozbase http server [1]. This is
>> already used internally for testing in Mozilla, so there is no problem
>> deploying it in a large automated testing scenario. It is also
>> relatively easy to customise, and doesn't require people running tests
>> to have the ability to compile C code (or to ship binaries for lots of
>> platforms).
>
> That actually looks like a very decent starting point. We can easily add
> API endpoints with specific behaviour that we need.

So, having looked at the code, and talked to the mozbase people, it 
seems like this might not be the easiest path; it's based on 
SimpleHTTPServer, which wants you to provide a response code, headers 
dict and body string. That's just not flexibility for our purposes, so 
it would be necessary to work around the existing behaviour to get what 
we want.

A more flexible option would be to use WSGI, which would give us a 
variety of production quality servers to work with. But you still can't 
get to .asis-levels of control because you have to return the status as 
a string and headers as a list of tuples, so you can't do things like 
vary the whitespace added, or add time delays whilst sending the body.

I don't know if anyone considers this sufficient reason to take a full 
NIH approach and start from raw sockets, or knows of an existing 
solution that we can build on that will allow the whole response, rather 
than just the body, to be defined by a function.

Received on Wednesday, 7 August 2013 22:32:52 UTC