Re: Simple Proposal for setting HTTP headers

Hello Tobie,

Many thanks for your answers.

On 2013/07/21 17:07, Tobie Langel wrote:
> On Saturday, July 20, 2013 at 9:35 AM, "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?",
>>
>
> Existing code (.htaccess) has a dependency we don't want to have: Apache. So either way we'll be writing code.

I got as far as understanding that some people don't want to depend on 
Apache. I haven't yet understood why. Pointer or explanation appreciated.

>> 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.
>>
>
> We'd be handling this in application-level code, so we'll only be writing it once. :)

I still don't understand this. Depending on what server you choose, some 
application code might work, and some other application code may not. As 
a (somewhat extreme) example, assume that I want to use Mongrel as a 
server. This is a server written in Ruby, and it won't be easy to run 
Python or PHP on it.


>>>> 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.
>>
>
> You're making some incorrect assumptions, here:
>
> 1) that supporting .htaccess is free. It's not. Some env we're looking at don't support it, so we'd have to implement a subset of it or change our architecture.
> 2) that developers are more familiar with .htaccess directives than writing raw HTTP headers (that's questionable and depends on their background).

Sure.

> 3) that working on tests rather than working on tooling is an effective strategy to get more tests. Data proves otherwise (e.g. idlharness).

It can of course be more efficient to work on tooling than on the tests 
themselves. It all depends. The most efficient thing to do is to use 
tools that already exist.

>> 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.
>>
>
> Yeah. That's not really an issue in this case.

Can you explain why, or provide a pointer?

>>>> 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.
>>
>
> What you're describing is an implementation strategy. What we're after for now is standardizing a format to let test author add HTTP headers to files, whatever the filetype.

Sorry, but I don't understand. Putting the headers at the start of the 
file, with an empty line between headers and body, already is a format.

The format itself works for both textual and binary files alike, and 
that seemed quite clear to me. Therefore, I interpreted your question as 
"how would I actually create such a file", and showed that it can be 
very easy.

The point that I made about this specific format is that it would 
already work "out of the box" on Apache. (I don't know about other servers.)


>>>> 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.
>>
>
> I'd be happy to just pick up an existing solution that meets our requirements. The closest I can find is raw HTTP headers in a separate file (similar to Mozilla's solution) or .htaccess files. Both  are not invented here, yet both imply writing code and come with a set of constraints. TBH, I'm not sure where you seeing us "get too hung up in useless complications and NIH syndrome."

Sorry I was a bit negative, but my assumption is still that different 
code may be needed for different servers, or otherwise we just end up 
with a limited list of servers.

This may work for the moment but doesn't guarantee that we won't have 
have somebody down the road saying "server A, B, or C don't work for me, 
I need this to run on server D, but I can't".

Regards,   Martin.

> Best,
>
> --tobie
>

Received on Monday, 22 July 2013 04:30:30 UTC