Re: Simple Proposal for setting HTTP headers

Hello Tobie, others,

Maybe I missed something, but was there any conclusion on this thread? 
Tobie, I'm fine with you choosing a solution, I think the thread overall 
brought up lots of good arguments, but now, we need a solution; whatever 
you choose will definitely be better than what we have now (namely nothing).

Regards,   Martin.

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.
>>
>> 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. :)
>>>> 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).
> 3) that working on tests rather than working on tooling is an effective strategy to get more tests. Data proves otherwise (e.g. idlharness).
>> 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.
>>>> 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.
>>>> 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."
>
> Best,
>
> --tobie
>

Received on Tuesday, 8 October 2013 08:21:01 UTC