Yep, the base support is trivial, just follow the instructions in
<http://search.cpan.org/dist/libwww-perl/README.SSL>.

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).

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 
http://validator.w3.org/check/referer 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.

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
www.w3.org, that should be changed.

"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 
servers?

Hmmm.

We really do want to serve as little as possible over SSL (reduce overhead) and keep 
serving as many badges as possible from www.w3.org. 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 v.w3.org ever could.

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?).

Target 0.7 and reassign to Olivier so he can investigate whether/how to best get
the www.w3.org badges served up over https/SSL.

starting to investigate whether we can serve icons from https://www.w3.org

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
<https://mydomain:8443/index_en.jsp>:

    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...)

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?

Retargeting 1.0. Doesn't look like anything will happen with this in time for 0.7.