Re: Simple Proposal for setting HTTP headers

This seems like a good 98% solution.

But in WebAppSec, we need a bit more sophisticated capability.  For CSP, we
need to be able to verify reports are sent, and reports are sent based on a
URI in the header.  So we do something like:
https://servername/csp/support/report.php?id=<randomnumber>, so we can go
and query later on <randomnumber> to see if the report contained what we
expected.

We also really want to be able to make sure that whatever policy string
that was set in the header is known definitively to the DOM for testing
purposes. (again, so we can verify reporting, e.g.)  In PHP we just set the
policy string as a variable and can access it when we set the header, and
later when checking the report, and know they're never out of sync.  That
would be much harder under this system.  (I guess we could have the same
string as a set-cookie and read that from the DOM..but ugh)

I don't mean to suggest complicating this particular proposal, only that
some groups may still need fully dynamic server-side capabilities.

-Brad


On Thu, Jul 18, 2013 at 12:41 PM, Tobie Langel <tobie@w3.org> wrote:

> Thanks for the feedback, Peter!
>
> On Thursday, July 18, 2013 at 6:58 PM, Peter Linss wrote:
> > A few concerns with this proposal though:
> >
> > 1) we need the ability to remove headers as well as add them (as is
> prevent default server behavior), at least for charset based on current use
> [1]. So we need some syntax to specify that.
> Overwriting the content-type header lets you do that already.
> > 2) we have a lot of cases where the same header is set for a large
> number of files in a directory. Having one header file per test file will
> cause a lot of extra files to be generated. Not a show stopper, but it
> might be nice to have the ability to specify a set of headers for multiple
> files in one place, especially for tests that have a set of related files
>
> I considered this. The downside is you have to depart from strict HTTP
> syntax to allow for per extensions directives, recursive dir handling, etc.
>
> TBH, I'd rather avoid having to deal with any of this until it really
> becomes an issue.
> > 3) having information necessary to execute a test properly in a separate
> file is generally a recipe for breakage. Another option might be to embed
> the header data inside the test file like we do for other metadata? Though
> this could be problematic for other file types like CSS and images…
>
> Yeah. Thought about that too. And came to the same conclusion as you did:
> how do you handle non HTML pages?
>
> --tobie
>
>