Topic on Project:Support desk

Hello, Dear All!

I've moved my Hebrew MediaWiki site, to a new hosting-service (iPage.com). I followed the migration guidelines by the letter (so I think, at least), but still the site is not working.

On Firefox, I get Content Encoding Error: The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

Unfortunately, I couldn't figure out how to fix that problem, so any advice would be much appreciated.

MW installation: 1.18.1, PHP: 5.1, MySQL: 5.0.91, Platform Type: Debian.

Thanks in advance for any help, Arnon

Hm, usually this error occurs, when you have corrupted files in your browser cache. So the usual fix is to clear the browser cache. However, I think this won't help you, as you get the error after changes on the server, not in your browser. I can also see that problem and I have never visited this site before, so I surely do not have corrupted files from that site in the cache.

However, this problem can also be caused by other things. One of them is a PHP error, which is given out and so somehow destroys the compression which the server tries to use. This here seems to be such a case. To check that, have a look at the PHP error log to see, if there are any errors reported.

> MW installation: 1.18.1, PHP: 5.1

Ha, that's it! Check the MediaWiki RELEASE-NOTES: MediaWiki 1.18 needs PHP 5.2.3 at least. You need to update PHP. :-)

Oops, sorry, my mistake: The actual PHP version is 5.3.13.

Looking at the cgi error log, all I can see for the recent message is the following: www.wikigenia.org.il/mw-config/index.php PHP Warning: file_get_contents(/hermes/bosweb/web172/b1728/ipg.wikigeniaorgil/wikigenia/includes/installer/../../RELEASE-NOTES) [function.file-get-contents]: failed to open stream: No such file or directory in /hermes/bosweb/web172/b1728/ipg.wikigeniaorgil/wikigenia/includes/installer/WebInstallerPage.php on line 1236

Does that make any sense?

Thanks, Arnonhersh (talk) 13:34, 1 November 2012 (UTC)

The problem is that the server is sending the HTTP header Content-Encoding: gzip as a response, but the content is not being encoded in gzip, it's in plain text (or plain HTML).

Your server is misconfigured. It's sending that header but it's not compressing the content. If I send a HTTP request without an Accept-Encoding: gzip, deflate, the page looks fine, since the server doesn't send that header.

The page that returns is a HTTP 404 error page anyway so it's not a misconfiguration of MediaWiki.

This post was posted by 88.13.92.60, but signed as Ciencia Al Poder.

Thanks much for making this problem easily understood for me.

Now, what would be the proper solution? What should I change in MediaWiki configuration?

Thanks!

I though it wasn't a MediaWiki related issue, but now I'm not entirely sure, since accessing a random script page works. It seems to be a combination of both:

• Accessing a really non-existant page doesn't output a Content-Encoding: gzip
• http://wikigenia.org.il/ redirects to a page (probably the configured main page), but it outputs a HTTP 404 page. The HTML generated is the same as the previous page, but this one has the Content-Encoding: gzip header.
• works.

It's probably a issue that can be fixed establishing $wgDisableOutputCompression as true. The fact that you copied LocalSettings from another host could explain that it doesn't work now, because your new host seems to not support gzip compression.

But even with that, when a page doesn't exist, your server is throwing the standard 404 error page instead of an empty MediaWiki page stating that the article doesn't exist. That one is a server configuration issue.

Well, I added $wgDisableOutputCompression and set it to true, but still - the very same error message is appearing in Firefox...

Any other suggestions as for how to fix it?...

Thanks much for the patience!

You must fix the configuration on the server that makes all HTTP 404 responses to be handled by a custom error page. Disable custom error pages on nginx (which seems to be your server)

Will that fix the compression problem as well? If not - what else should I do besides adding the disabling-compression parameter (which I did)?

Thanks much!

I don't know, but compression doesn't seem to be an issue once your server stops sending a weird custom HTTP 404 error page when MediaWiki issues a 404 response for pages not existing in your wiki. As I posted earlier, a link to Special:RecentChanges works. The problem is that interception of the 404 responses.

Thanks for clarifying this. I'm now discussing this with the support of my hosting service.

Hi, again.

The support team of my hosting service (iPage.com) insists that there's no problem on their side. Here's the server's php info, maybe it will help identifying something.

Any more ideas?

I'm really lost here and I really need this site to properly work asap...

Sorry for bugging and thanks in advance.

Read this, it's likely your problem. Again, the fact that when an article is not present and MediaWiki issues a HTTP 404 response, the server intercepts it and changes the output to its custom error page demonstrates that's not a MediaWiki issue:

http://till.klampaeckel.de/blog/archives/148-nginx-configuration-gotchas.html

Thanks much for that and for your much appreciated patience.

I'm not that familiar with servers, but I can't find anywhere on my hosting service's admin page anything related to nginx. How can I make sure it's indeed my server? And suppose it is (I'm assuming you know much more about it that I do ;-) - how can I turn off the needed parameter (as shown in the link you were referring)?

Thanks much again and again!

Well, your server responses send the header "Server: Nginx / Varnish", that's why I posted that link. If you're configuring things through an admin page of a hosting service, try looking at a "custom error pages", or ask directly to the support team how to disable them. Also, you may want to post them a link to this forum.

I tried this already. I do have a "Custom Error Pages" interface under ".htaccess editor", but all I can do there is add URLs to local paths. Should I use that?

You should remove any custom 404 error page

But there isn't anything customized there... All the .htaccess has is "DirectoryIndex index.php". That's it...

It might be that I'm up on something: URLs with no Hebrew characters seem to work, check Soundex, JewishGen, JOWBR; even categories with English names work although there's the word "category" in Hebrew within the URL, for example JewishGen Category.

There is, however, some problem with the Hebrew... For example, this page has only English in its URL, it redirects to another page which is uploaded, but then the Hebrew title is corrupted (the other Hebrew text is fine). Same for the category JewishGen which is uploaded but the Hebrew page-names are corrupted.

Pages with Hebrew title are not uploaded correctly, for example this one, or this category.

I hope it sheds light on some other potential problem(s)...

Thanks!

You don't seem to understand... When you view a page with a title that doesn't exist on the database, MediaWiki sends a normal page but with no "content", except the message that says the page doesn't exist yet. And the response is with a HTTP 404 response, so search engines don't index that content and the browser don't cache the page.

When MediaWiki does a HTTP 404 response, that response is intercepted by your web server and instead it sends a custom error page instead of MediaWiki's response.

This image demonstrates that: http://img687.imageshack.us/img687/5548/wikiwithnoacceptencodin.png

You would only see it if you use a browser that doesn't accept compression, or by modifying the HTTP headers, removing the Accept-Encoding one as I did. This is the problem, and it's not caused by MediaWiki but by your webserver.

It has nothing to do with Hebrew or other strange characters. See for example this simple one: . As I said, that only happens when the page doesn't exist on the wiki.

If you're paying for that service you should demand a prompt resolution of this issue. If they're unable/willing to help you I strongly encourage you to find a better service.

Thanks for the enlightening explanation. I think that I get most of it by now.

There is however a possible glitch in my understanding: The page that you were trying to load, the one for which you took the screenshot, does exist in my system. Were you able to upload it after changing the HTTP header via your browser? I'm just trying to understand whether it's only one problem (404 intercepted by the server) or actually two (as English URLs do work and Hebrew-URLs don't).

I do pay to that service provider (in that case, non-provider...), and I'm seriously considering moving the system (again) to a new server (any recommendations?).

Thanks much!

Yes, in addition to that you may be facing a weird encoding error as seen in Special:AllPages. Probably the data import on de database was wrong, and the likely cause is file encoding if the filesystem or the shell has no UTF-8 (unicode) support,

Thanks for that, so I did understand it correctly.

Now, I guess it'd be the last question: Considering everything that we've seen here, what exactly should I tell the support staff of my hosting service?

Arnon

My response on Nivember, 6 should be sufficient.