Wordpress SSL causes 404 for images

After installing first a self-signed SSL certificate (replaced with a free Comodo SSL certificate in order to troubleshoot this problem) I installed Wordpress and started building a WooCommerce-based store. Because I'd installed Wordpress on the https:// site, the Settings > General screen automatically configured the site address as https://

All was going well apart from a niggling problem with images not displaying on the site itself (anonymously) or logged into the WP dashboard. Inspecting the image HTML in Chrome allowed me to extract the full problem URL and I found I could load the image successfully in its own window. Chrome also allowed flagged the 404 response for images when loaded through the Wordpress page. Weird.

Apart from images I uploaded to the Media library, other images being served locally from my Wordpress installation (e.g. theme thumbnails) were also failing to load.

I found that by changing the site address (again in WP > Settings > General) to http:// (not https://) the images would display so I came to believe the problem was somehow related to SSL. Interestingly, after changing this setting, the images appeared when I browsed to either the http:// or https:// site. Images on the http:// site using absolute image references to the https:// site also worked.

After a bit of head scratching and a bit of searching around (this problem doesn't seem to be particularly common), I came across this page which suggests hotlink protection can cause problems for the SSL protocol. Apparently "HTTPS is configured correctly when resources that are available via HTTP are also available via HTTPS." As far I could tell, my images were available through both HTTP and HTTPS but I had enabled hotlink protection on the site before installing Wordpress.

Sure enough, disabling hotlink protection solved the problem.

Presenting at the next SharePoint User Group Presentation

Just a reminder I’ll be delivering part two of my two-part presentation on how we do web content management on MOSS 2007 this Tuesday at 12:30pm. We had a great turnout for the first presentation so it will be interesting to see who comes back!! Honestly, it’s amazing how many of you SharePoint/MOSS guys I’ve met through the first presentation and I’m really looking forward to bumping into a few more of you—please come up and say hello!

The blurb on the user group site is a straight copy of the part one blurb so here’s what I’ll be talking about tomorrow:

westernaustralia.com was one of the first public-facing MOSS 2007-based internet sites launched in Australia and is billed as the Western Australia Tourism Commission’s flagship web site. Two years on and thirty MCMS 2002-based tourism sites are now being migrated to the MOSS 2007 platform. In the second segment of this two part presentation, Michael Hanes, the Development Coordinator/Tech Lead at Tourism WA, talks about the backend MOSS environments. In this presentation Michael presents the existing and replacement hardware environments, virtualisation, environment structure, farm configuration, security, site collection structure and variations, performance, tooling, content delivery (Akamai), and content deployment.

Jeremy’s aiming to record the presentation again so, all being well, the part two webcast will be available after the event in case you’re unable to come along.

Here’s part one in case you missed it. See you down there for part two!!

[Update: a vodcast of the presentation is now available here with a PDF of the slides and notes here.]

[Update: the original PowerPoint deck is now available.]

Fixing the IE7/MOSS/HTTP 413/Client SSL/View State White Screen of Death

Content on the Tourism WA partner sites like Australia's Golden Outback needs to be accessible by content editors over the internet. To facilitate this, we use client certificates over SSL to authenticate users. Each certificate is additionally mapped to an Active Directory account to support granular control over specific assets and provide standard "auditing" (in the MOSS version history sense) of user activity. Users additionally benefit from a single sign-on experience since IE hands off the client certificate in a relatively seamless manner.

In the image below the first box describes how client certifcates are created and provided to the content editors; the second box describes how IE and IIS authenticate the user to MOSS via AD.

This approach looks pretty nice on paper apart from the manual task of creating the client certificate and the potential distribution security. Our external content editor user base is fairly small and well-known, however.

Following the launch of the first partner site using this security model, we came across a painful situation I'll describe here but hope you never encounter in the field. If you have come across this problem, hopefully this post will steer you in the right direction. 

So the problem: 

When attempting to save, check in, or publish a page, IE content editors were presented with a white screen (a page with nothing in it, more specifically) in a relatively short timeframe. The problem appeared to be sporadic and definitely affect some pages but not others.

Inspecting the content editor's machine revealed no hardware or software issues and nothing was logged to the client's event logs. The HTML source was nothing special with the IE Dev Toolbar telling the same story:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>

<BODY></BODY></HTML>

Although some basic IE security and JS settings were tweaked, friendly error messages were already turned off. As our initial user base was regionally-based and we mistakenly believed we couldn't reproduce the problem on the local network, we initially ascribed the problem to a lousy, congested regional network connection. I say we mistakenly believed we couldn't reproduce the problem because we generally use the non-SSL-secured internal site at head office due to an unrelated issue. 

This wasn't a lot to go on and we struggled to diagnose the problem while waiting for the installation of a WAN accellerator upgrade to our own regional office to prove or disprove our theory about the network infrastructure. Meanwhile, our third partner site came online and the content editors logged the same issue; this time, those content editors were sitting in Perth on metropolitain ADSL 2+ wires.

With the installation of a broadband connection at home I decided to see what I could find out outside the corporate environment. I logged into to one of the secure sites and got lucky--I was finally able to reproduce the problem on one of every five or so attempts to save a rather large page. 

With that achievement under my hat I fired up my trusty friend Fiddler 2 and reloaded the site. As I mentioned above, the partner sites are delivered to content editors over an SSL-secured (443) connection; in other words, that means inspecting the HTML request/response data outside the browser would normally be a bit tricky. Luckily Fiddler 2 makes this easy--you simply need to check the Decrypt HTTPS traffic checkbox in the Fiddler settings (under Proxy Settings) and Fiddler will present you with the goods. 

In my case that was step one but step 2 meant I'd also have to hand over a valid client certificate since Fiddler essentially does the man in the middle thing to pull off the SSL decryption bit. Fiddler's documentation is pretty good on this subject so after exporting my existing certificate with a .cer extension I dropped it into My Documents\Fiddler2\ClientCertificate.cer (named exactly as shown). At long last I could not only reproduce the problem but I could even see under the covers of the HTTP protocol!

And it was that simple: hitting the same problem page a few times and Fiddler told me it was all about a lousy HTTP 413 error--all this for a bloody error code IE should have been showing me in the first place. 

Here's the request:

POST /en/ThisPageIsTroubba.aspx HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/x-shockwave-flash, application/x-silverlight, application/x-silverlight-2-b2, */*

Referer: https://edit.problemsite.com/en/ThisPageIsTroubba.aspx

Accept-Language: en-au,en-GB;q=0.5

Content-Type: application/x-www-form-urlencoded

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Host: edit.problemsite.com

Content-Length: 71069

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: WSS_KeepSessionAuthenticated=443; MSOWebPartPage_AnonymousAccessCookie=443; s_cc=true; s_sq=%5B%5BB%5D%5D

 

HTTP/1.1 413 Request Entity Too Large

Content-Length: 0

Server: Microsoft-IIS/6.0

X-Powered-By: ASP.NET

Date: Sun, 02 Nov 2008 10:47:22 GMT

Connection: close

"What is an HTTP 413 error," I asked, just like you may be doing now? It means the server rejected the request because it considered it too big. Weird, considering the request was only just over 71KB but at least we could rule out the network--a good thing because a lot of our future content editors are very much regional.

The w3c tells us the following about HTTP 413:

"The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

 

If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again."

I mentioned page weight previously and the title of this posting also ties in viewstate. Why? I've already suggested the white screen problem seemed to affect some pages but not others. While investigating this problem, I noted the viewstate on most of the anonymous partner site pages is very low at a <2KB.

Still with me? 

We're currently running on Windows 2003 and IIS 6.0. When IIS has to deal with client certificates, the server uses the UploadReadAheadSize metabase property during the SSL preload process to determine the maximum buffer size for the incoming request. The default buffer size is 48KB to prevent denial of service attacks and for that reason Microsoft doesn't recommend setting it too high. In our case, the 71KB request was considered too large and IIS wouldn't let it through. Why the save/check-in/publish worked sporadically I can't say, but increasing the value assigned to this property instantly fixed the problem. We increased this setting on every relevant IIS web site using this command:

cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800

Note the setting represents bytes, not kilobytes, and the TechNet article on changing this is incorrectly specifies a value of 200.

In theory the HTTP 413 should have come up in the server logs but if it did, we never caught it. 

For more information about the metabase changes, the following blog posts may be of use:

• "HTTP 413 Request Entity too Large - Can't upload large files using IIS6"
  
• "The "White Screen" Bug in IE with ASP.NET"

---

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com