Re: Simple Proposal for setting HTTP headers

We mostly get around the multiple hostnames problem by using "localhost"
and "127.0.0.1" and multiple ports.

I'm not sure what you mean by "trusted"; could you be a little more
detailed? I'm curious if there's something we wouldn't be able to support.

-- Dirk

On Tue, Jul 23, 2013 at 6:33 AM, Brad Hill <hillbrad@gmail.com> wrote:

> Again, WebAppSec is an outlier, though not the only one.  I never expect
> or tests to work 100% from a mass-deployed local server as we depend on
> having multiple host names and, critically, having a trusted https endpoint
> available for our tests.
>  -brad
> On Jul 23, 2013 3:42 AM, "Richard Ishida" <ishida@w3.org> wrote:
>
>> On 23/07/2013 09:45, James Graham wrote:
>>
>>> Mozilla use a custom HTTP server written in javascript (using
>>> Mozilla-specific APIs). This is part of the source so no special install
>>> is required.
>>>
>>
>> I have no intention of installing another server on my system. I will
>> create the additional files needed for the new approach, but continue to
>> use a .htaccess file on my local server to check that the tests work before
>> submission.
>>
>>  Obviously no one is suggesting using file:// for testing since that has
>>> quite different semantics from HTTP. It already doesn't work to run even
>>> static tests over file:// since they depend on /resources/.
>>>
>>
>> It doesn't work when using a localhost server, either, which is
>> irritating, to be honest. I generate my tests from PHP scripts, so I can
>> use absolute uris for checking until just before submitting, then
>> regenerate the tests with /resources URLs. It must be particularly
>> irritating though if you are just creating flat files, and having to edit
>> all of them before submission, and I see it as a burden on the test writer
>> that's not necessary. (Perhaps not a major issue if you are just creating
>> one or two tests at a time, but I have just created 601 tests just for the
>> line breaking feature for CSS3 Text, and they all need to be changed for
>> this.)
>>
>> RI
>>
>>
>> --
>> Richard Ishida, W3C
>> http://rishida.net/
>>
>>