Re: Simple Proposal for setting HTTP headers

By trusted, I mean that several features are required to fail without user
recourse if the presented HTTPS certificate is not valid, issued from a
trusted root CA, matches the correct hostname, etc.  The only practical way
to work around this for local testing is to have a dummy cert that is
manually added to the local browser's trust store.  Not out of the
question, of course, but another wrinkle.

Right now, the server at w3c-test.org supports listening on:

w3c-test.org
www.w3c-test.org
www2.w3c-test.org
www3.w3c-test.org

and on ports 80, 81, 82, 83, 88 and 8081
as well as HTTPS on 443.

I suppose we can re-design the tests to do something else, but this is the
infrastructure we've had for years and have hundreds of tests depending on
it.

-Brad


On Tue, Jul 23, 2013 at 10:01 AM, Dirk Pranke <dpranke@chromium.org> wrote:

> 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/
>>>
>>>
>