Really Ugly Error

You come across ugly errors from time to time.  Like the one today someone pointed me to where was down, the site said “Service unavailable http/1”.  What’s frustrating is when that error is really ugly, under your control and you can’t quickly uncover a root cause.  When that happens, you often look around on the Net for a solution.  But when that fails to produce results, you have to go back to pulling out your hair.  What’s even more frustrating than all of this though is when this is time spent on something stupid, something that doesn’t add value, something that does you no good, something that doesn’t make you money or make you a better person.  Just wasting time.  Well, this is one of those things.

Enough venting and I hope this post will get indexed by some search engines and help someone out.

Now here’s the error: kCFErrorDomainCFNetwork (click on the embedded image over there for a closeup of what I’m talking about).



And here’s how I came across it: While using an iPad, I noticed that I was having issues downloading PDF files into GoodReader.  I thought maybe it was a GoodReader issue.  But as I started using other platforms, like Safari mobile and Safari desktop, I found the issue kept popping up intermittently (oh yes, this was an intermittent thing too…the issue sometimes appears on the same document and other times does not…and if the error does appear, I can simply do a refresh a few times and it will often work).  I tried it from multiple locations, multiple computers and all that normal troubleshooting to rule out network issues.

In the end, here’s what I found to be the work around: I found that if I removed the S from the HTTPS, everything worked without a hitch.  Through Googling about the issue, I found several other reasons why this error occurs, but wanted to add this to the mix since I hadn’t run across it yet.  Again, it seems in my case having the PDF delivered through a secure protocol presents the problem.

I need to point out though that it probably has nothing to do with SSL technology.  It probably has something to do with the way the response is being crafted.  Unfortunately, I can’t figure out what that is.  Anyhow, here is the technology being used to serve up that PDF:  IIS webserver, SSL, legit cert, PDF document handler (web.config, IIS integrated, PDF extension, calls document handler code, etc).  The pdf handler code does something like this pseudo code.

context.Response.AddHeader("Content-Type", "application/pdf")

So I’ve tried just about every combination of working with the context response that I can think of…setting a Content-Length, setting other metadata like cacheability, expirations etc…I can’t get a combination correct. So I have to think it has something to do with the code. I can’t imagine it’s something with the technologies in play – compatibility with Apple/MicroSoft, SSL cert, etc. I believe I reproduced this in Google Chrome so that kind of reinforces my thought that it has something to do with the code, but I won’t rule anything out at this point. But, when I take the S off and deliver the PDF over regular HTTP, everything is fine.

That still doesn’t solve my problem where I need the S on the end though…hmmm…but I hope this post helps someone really smart figure it out before I do.  If that’s you, please let me know.  :>

Leave a comment


  1. We got it fixed! Whewhew!! context.Response.AddHeader(“Content-Length”, file.Length.ToString()). I thought we had that in place, but I guess we missed it and/or tried it in combination with other things that invalidated it. Anyhow, this did it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: