Re: Simple Proposal for setting HTTP headers

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 Sunday, 21 July 2013 08:07:15 UTC