Hi -- we understand your requirement.  We will need to investigate what it 
takes to support HTTPS for resources.  Out of curiosity, why do you need to 
server resources under HTTPS?

I understand the need to serve HTML under HTTPS since it's frequently is 
dynamically generated with private data.  But are your javascript, css, and 
image files also personalized?

There are two reasons we have everything served under HTTPS:

Primarily our customers find it unacceptable to receive the security warning 
that appears in most if not all browsers when mixed HTTP/HTTPS content is 
present in a page. If there is a way to not have that warning appear, then we 
would be willing to switch that content from HTTPS to HTTP.

Second, per Adam Langley 
(http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html) SSL is not 
computationally expensive anymore. Therefore, having the requested URLs and 
resources encrypted provides additional security to the users by, for example, 
not exposing what host they are visiting or what section of the site they are 
using, which could possibly be exposed by path names in images or js files.

I admit #2 is rather paranoid and not a strictly necessary level of security, 
but considering #1 at the same time, encrypting everything makes a certain kind 
of sense. :(

I'm definitely open to suggestions. Thanks!

One additional thought -- our static content is not yet served from a 
cookie-less domain. We're working on that, but it's a reasonably big 
architectural change for our environment. Therefore, having that content not 
encrypted means Cookies would traverse the net in plain text.

I understand that there are some interesting problems to solve in order for 
mod_pagespeed to be able to support retrieval of resources over an ssl/tls 
connection, but I believe that this would be a valuable feature for any site 
that offers services to its users over a secure connection. In the case of 
ssl/tls reducing round trip time and optimizing caching seem to become even 
more important than with standard http.

One simple(read hackish) possibility that keeps mod_pagespeed from having to 
support ssl would be to allow for an option that tells mod_pagespeed to rewrite 
urls as https instead of http. That way clients would request the https 
resource even though mod_pagespeed requested the http resource.

I agree with opiate@ that mixed http/https content warnings are a deal-breaker. 
we should provide full https support

Merging with authenticated HTTP request

Issue 65 has been merged into this issue.

See Issue 188

Issue 331 has been merged into this issue.

Do you have an ETA for this feature?

No ETA yet, frederic...  There are a few issues we have not had time to tackle, 
but it's perhaps not necessary to address all of them to solve your specific 
issue.

The challenge we want to defer is initiating https fetches from mod_pagespeed.

But this is not necessary if we can define 'https support' via domain-mapping 
directives.  E.g. if you supply "ModPagespeedMapOriginDomain" directives to map 
https resources to localhost, or "ModPagespeedLoadFromFile" directives to read 
them directly from disk, then it should be fine to resources identified in HTML 
using https URLs.

Would that be sufficient?  This would be a much simpler task because it 
requires simply removing restrictions that we put into our domain-mapping code 
and adding tests.

Thanks!

Also, frederic...would you be able to build & test from trunk?  Or do you 
require a binary release to test?

Hmm... from reading your comment on the proposed solution, this would certainly 
work for us. We use Apache as a HTTPS frontend to Java application servers but 
also serve static content from local disk. From what you are saying, I should 
be able to use HTTPS today simply by specifying either 
ModPagespeedMapOriginDomain to the App servers or ModPagespeedLoadFromFile from 
the local files? Or would I still require a new build?

I would be happy to build and test from trunk..

You can't do it yet but it wouldn't be hard to allow it.

I'm in a similiar situation as some of the above posters. Loading the resources 
through ModPagespeedLoadFromFile would be a definite possibility. Adding the 
ability to pattern-match on the filename to the directive would be highly 
beneficial, as in "apply directive if basename of resource ends in .css, .js, 
.jpg, .gif or .png, otherwise ignore".

It would be great if you could allow this for HTTPS resources. To be honest I 
wasn't even sure mod_pagespeed was working until I found cached files from 
another site on the server - maybe a note explaining that SSL operation is not 
supported/requires extra configuration in the installation instructions would 
be a good idea.

Thanks for this great tool!

On one of my domains I have configured this:
    ModPagespeed on
    ModPagespeedDomain https://www.dvdupgrades.ch
    ModPagespeedDomain http://www.dvdupgrades.ch
    ModPagespeedMapOriginDomain localhost *dvdupgrades.ch
    ModPagespeedMapOriginDomain localhost *.dvdupgrades.ch
    ModPagespeedFileCachePath "/home/shop/www/mod_pagespeed/cache/"
    ModPagespeedGeneratedFilePrefix "/home/shop/www/mod_pagespeed/files/"
    AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html
    ModPagespeedEnableFilters move_css_to_head,combine_css,rewrite_css,rewrite_javascript,combine_javascript
    ModPagespeedDisableFilters inline_css,inline_javascript,trim_urls

Result: none. My css and javascript files are still not combined. These flies 
are available under http and https and at dvdupgrades.ch and localhost. The 
main content (html) is only available under the https address.

I can build from source, make patches and install this or that. Best thing is 
if you contacted me under fst [at] highdefinition.ch

[deleted comment]

I hate to jump ahead of the game, but did this change to allow http or local 
file access already get committed?

http://code.google.com/p/modpagespeed/source/detail?r=918

Not yet.  Some changes have gone in but the whole flow isn't working yet.

It would be helpful if you noted / highlighted the lack of this feature on the 
module homepage/download page.  I've spent a day installing and trying to 
figure out its behaviour.

My apologies for not updating this issue (*) when I committed 
http://code.google.com/p/modpagespeed/source/detail?r=918 but yes, this should 
fix Frederic's problem (a build from source will be required).
I tested Frederic's setup manually (as best I could) and it seemed to work OK, 
so please try it and update this issue with results.
(*) I went on vacation shortly after and just got back. Mea culpa :-(

This is working.. mostly!

The relevant configuration lines are:
    ModPagespeedDomain http://test1optimized.rallydev.com
    ModPagespeedDomain https://test1optimized.rallydev.com
    ModPagespeedDomain http://test1cdn*.rallydev.com
    ModPagespeedDomain https://test1cdn*.rallydev.com
    ModPagespeedMapOriginDomain http://localhost http://test1optimized.rallydev.com
    ModPagespeedMapOriginDomain http://localhost https://test1optimized.rallydev.com
    ModPagespeedShardDomain https://test1optimized.rallydev.com https://test1cdn1.rallydev.com,https://test1cdn2.rallydev.com,https://test1cdn3.rallydev.com

(Note: there are a lot of testing http versions above. I would remove lines 1, 
3, 5 above if I wanted https only)

To get ModPagespeedShardDomain to work, I had to modify 
net/instaweb/rewriter/domain_lawyer.cc and comment out the if 
(!IsSchemeHttp...) statement like this:

bool DomainLawyer::MapDomainHelper(
    const StringPiece& to_domain_name,
    const StringPiece& comma_separated_from_domains,
    SetDomainFn set_domain_fn,
    bool allow_wildcards,
    bool authorize_to_domain,
    MessageHandler* handler) {
  // TODO(matterbury): remove this condition once it's 'safe' to do so,
  // namely we've validated that downstream components (such as the fetcher)
  // handle https sanely.
  //if (!IsSchemeHttpOrMissing(to_domain_name)) {
  //  return false;
  //}
  Domain* to_domain = AddDomainHelper(to_domain_name, false,
                                      authorize_to_domain, handler);
  if (to_domain == NULL) {


Can we get this change committed?

Thanks very much for the feedback!
I will add some tests for this then make the change as soon as possible, 
assuming there's no breakage from it.

I have committed this change 
http://code.google.com/p/modpagespeed/source/detail?r=988 to allow sharding and 
rewriting to an https scheme. It was slightly more complicated than simply 
removing the check because we don't want to allow just any old scheme, and we 
don't want to allow origin mapping to https since Apache doesn't support it.

I would appreciate it if you could build from source and let me know how it 
goes for you.

Regards, m.

Presuming this is now fixed.

I can confirm that this works as expected so far.

Thank you!

Thanks for the feedback, and of course don't hesitate to get in touch if you 
have any problems :-)