Re: Simple Proposal for setting HTTP headers

On 2013-07-23 20:26, Brad Hill wrote:
> 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.

That sounds reasonable for the browser vendor testing use case.

> Right now, the server at w3c-test.org [2] supports listening on:
> 
> w3c-test.org [2]
>  www.w3c-test.org [3]
> www2.w3c-test.org [4]
> www3.w3c-test.org [5]
> 
> and on ports 80, 81, 82, 83, 88 and 8081
> as well as HTTPS on 443.

Yes, that set of subdomains and ports are a requirement. Generally (but 
not always) one can design tests to avoid depending on the explicit tld 
by using relative urls, introspecting window.location.

> 
> 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/ [1]
> 
> 
> 
> Links:
> ------
> [1] http://rishida.net/
> [2] http://w3c-test.org
> [3] http://www.w3c-test.org
> [4] http://www2.w3c-test.org
> [5] http://www3.w3c-test.org

Received on Tuesday, 23 July 2013 19:04:06 UTC