This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 77 - Support for SSL/TLS (https://). also on non-standard ports
Summary: Support for SSL/TLS (https://). also on non-standard ports
Alias: None
Product: Validator
Classification: Unclassified
Component: check (show other bugs)
Version: 0.6.0
Hardware: Other other
: P2 enhancement
Target Milestone: 1.0
Assignee: This bug has no owner yet - up for the taking
QA Contact: qa-dev tracking
Depends on: 117
  Show dependency treegraph
Reported: 2002-11-23 23:18 UTC by Terje Bless
Modified: 2010-08-04 23:23 UTC (History)
1 user (show)

See Also:


Description Terje Bless 2002-11-23 23:18:10 UTC
Validator should support SSL/TLS for fetching pages to validate.
Comment 1 Ville Skyttä 2002-11-29 18:09:33 UTC
Yep, the base support is trivial, just follow the instructions in

But one thing to notice is RFC2616, section 15.1.3:

     Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP
     request if the referring page was transferred with a secure protocol. 

This means that the "Valid XYZ" badges need to use https in the referer link if
the validated resource had a https URI, or else it just might not work [1]. 
This requires some tweaking; the scheme part of the badge URI comes from the
"Home Page" config parameter currently.  Maybe that parameter should be ditched
altogether, and {Env}->{'Self Uri'} together with URI->new_abs() used instead.

And if someone has validated a https resource using a validator with a
*non*-https URI, things get hairier.  We need to check if https is in the list
of allowed protocols, and if it actually works (ie. call
$ua->is_protocol_allowed).  If https is ok, no problem, use it in the link, but
if it's not, we need to output a blurb about this :#

[1] I tried this out some time ago with multiple browsers, and Konqueror 3.0.3
was the only tested one that happily sent Referer from a https to a http URI
(bug reported, and AFAICT fixed in KDE CVS).
Comment 2 Terje Bless 2002-11-29 18:48:29 UTC
I see no great problem with this. It's rather intrusive so it'll have to go into 0.7.0 or later, 
but the logic seems to be manageable.

It doesn't matter where the badge itself resides; the interesting bit is whether the link uses http or https as the scheme. 
Conditionalizing this on whether the URI we just checked was http or https seems trivial.

Not sure what the best way is to provide configuration for the URL of the service, but 
several options present themselves. The most immediately obvious is to simply have two 
configuration parameters; one for the http version of the Validator and another for the 
https version.

I'm planning to rip the config files apart and reassemble them in a different way in any 
case, so this change is trivial by comparison.
Comment 3 Ville Skyttä 2002-11-30 06:00:29 UTC
Actually, I am worried about the correct thing, but the explanation was crap,
the decision whether to output a http or https link to the validator has nothing
to do with allowed_protocols.  Dunno what I was smoking :)

It might actually be so that the two "Home_Page" URIs are needed.

Oh, and the badge images need to come through https as well on a https
validator, otherwise browsers will yell.  There are some that point to, that should be changed.
Comment 4 Terje Bless 2002-11-30 14:43:15 UTC
"Oh, and the badge images need to come through https as well on a https
 validator, otherwise browsers will yell."

You're refering to the warning that some elements on a page come from non-secure 


We really do want to serve as little as possible over SSL (reduce overhead) and keep 
serving as many badges as possible from The latter is round-robin 
load-balanced among a whole bunch of physical boxes around the world, so it can take 
far more of a beating then ever could.
Comment 5 Ville Skyttä 2002-11-30 17:58:18 UTC
Yes, that's what I'm referring to.  And eek, this may actually be a tough one to
get completely done.  But IIRC the badges can come from somewhere else than
v.w.o, as long as every URI in a page fetched over https is a https one.

Of course, one option is just not to support "check/referer"-style links over
HTTPS (or support 'em only if we know for sure that HTTPS is enabled on the
validator instance, eg. from the new SSL_Home_Page conf var?).
Comment 6 Terje Bless 2003-05-23 12:51:32 UTC
Target 0.7 and reassign to Olivier so he can investigate whether/how to best get
the badges served up over https/SSL.
Comment 7 Olivier Thereaux 2003-07-22 21:51:27 UTC
starting to investigate whether we can serve icons from
Comment 8 Ralf Hauser 2003-08-10 10:20:50 UTC
while it appears that redirects from https://hostname:443 to say
https://hostname:8443 are handled perfectly nicely (at least for pages ending in
.htm), when I directly enter the port, I got

<< I got the following unexpected response when trying to retrieve

    500 No Context configured to process this request

Please make sure you have entered the URI correctly.>>

The jsp is served from tomcat/struts, but I assume that this (and the ".jsp"
file extension) isn't reason for the problem (at least when I save the page to
html with Mozilla, and serve this static file.htm from 443, it works...)
Comment 9 Ville Skyttä 2003-09-02 13:45:31 UTC
Ralf, I guess that's a Tomcat (?) configuration issue or a bug, maybe it doesn't
grok the Host: header sent by the validator (if it contains a port, untested).

Could you post a public URI to where this can be reproduced?
Comment 10 Terje Bless 2004-09-01 16:31:47 UTC
Retargeting 1.0. Doesn't look like anything will happen with this in time for 0.7.