Is our .htaccess working for you?

As you may know, Unity WebGL will write an invisible .htaccess file into the Release folder of builds in order to instruct the web server to host the build files using gzip compression on the http transfer level, allowing browsers to decompress the data while downloading.

In 5.3, Unity will fall back to decompressing gzip in JavaScript if the server setup does not work, so you will always get compressed transfers, but you may have a few hundred ms of extra decompression time after the download if decompression is not handled by the protocol. Which means that having the server configured to handle compression is no longer a hard requirement for shipping anything, but is more like a minor optimization you can take.

Now, I have seen plenty of threads now (and in the past) about the default .htaccess file we provide causing problems with many web servers and requiring changes. Now I’m wondering what to do here. Given that there are endless different web server configurations out there, it is very hard to come up with a configuration which will work everywhere. Given that 5.3 will give decent results using it’s fallback JavaScript compression, I am wondering if we should just stop supplying a .htaccess file to avoid such issues - and when people want to benefit from http-level compression, they can set up such a file themselves.

In order to make such a decision, I’d like to figure out how many people are having such problems. Is it a vocal minority on this forum, or most users, or somewhere in between? So, please comment on this thread and/or use the attached poll.

Microsoft Azure (IIS) seems to ignore .htaccess files and needs custom web.config to work. Any chance you could generate that as well?

1 Like

Hello,

before 5.3 I was able to host my files. I tried the compression way to do it, but failed, and sticked to uncompressed.
Now in 5.3 I struggle to get anything running at all.
The build output seems to be always compressed and I receive an internal server error:
ā€œFailed to load resource: the server responded with a status of 500 (Internal Server Error)ā€

I really cant figure out why, I would love to make the compression approach work, but if not, I can not see how to use an umcompressed way in 5.3, can someone help me here?

On topic I would say to remove the .htaccess and include all about compression in the documentation only? For me it made more trouble than anything else so far :frowning:

Blue

So, if you delete the .htaccess file on your server, will it work?

This is what we will probably do.

hello and thanks for your reply.

I already tried deleting the .htaccess. Result:
ā€œUnityLoader.js:1 Invoking error handler due to
Uncaught SyntaxError: Unexpected token <ā€

ā€œUncaught SyntaxError: Unexpected token <
blob:http%3A//www.i-show-you.de/de364561-e69d-4d7a-b910-47660802ae90:1ā€

My guess is that the loader is running but fails to decompress the files? Cant find out what is exactly happening.

Blue

I’m using nodeJS + Express on the server side, so I don’t need ā€œ.htaccessā€ files.
However, for 5.2 builds I wrote some code to sent gzipped content to client.

I’m getting the following error even after deleting the .htaccess file in the Release folder:

ā€œAn error occured running the Unity content on this page. See your browser’s JavaScript console for more info. The error was: uncaught exception: unknown compression methodā€

My game seems to load up fine after I click Ok though.

same here , it happens sometimes and with some users only, there is no fix pattern.

Is the .htaccess file needed for Development builds? It is being added to the Development folder automatically. The file extensions are .data, .js and .mem so they shouldn’t need to be decompressed, right?

Ubuntu 14.04 Server+Apache, having the .htaccess gives :
GET http://x.x.x.x/ll/Release/UnityLoader.js 500 (Internal Server Error)

Had to remove it to get it to work.

I have the default generated (5.3.1f1) Release/.htaccess file in place… but to get this to work from our Unix Apache server I have to amend the index.html file generated to ADD gz on end of the three URLs… i.e. changing those to .datagz, .jsgz and .memgz

If not I get the error others report. SyntaxError: expected expression, got ā€˜<’

But with the modified index.html version it does not work when tested from a local file store. Using Firefox 43.0.1.

My full report is at

It seems that a RewriteBase needs to be added to the .htaccess file… and we moved it up to the index.html level, though I am no sure that is required.

We host all of our files on amazon s3 and cloudfront, so as of now we are making the assumption that all of our users browsers who can run web gl will support gzip encoding. It appears that all major browsers have had this for the past 10 years-ish?

So we don’t actually use your .htacess concept or the fallback of adding ā€œgzā€ to the end of the url. I would love to be able to do use that but since there isn’t currently a (easy out of the box) way for us to sign the request for downloading in amazon (making the files public isn’t ideal for us at this point) and because cloudfront doesnt support gzipping the .data and .mem files by default (it does for the javascript file, but it doesnt like binary files apparently)

I hope this information is helpful.

I was not able to get the webgl build running properly on my server. The server is Ubuntu (Linux Mint) Apache2. What did the trick was to make sure that (1) mod_delegate AND (2) mod_rewrite were up and running. After that, the gz files downloaded very fast, using the .htaccess out of the box from unity. The transferred to size ratio for the jsgz, datagz, and memgz files went down to .23 to 1.00 on average. The major problem had been from the /var/log/apache2/error.log was:

.htaccess: Invalid command ā€˜RewriteEngine’, perhaps misspelled or defined by a module not included in the server configuration

So, if your admin doesn’t have both mods up and running, then the whole project dies, unless you delete the .htaccess file altogether.

We’re getting errors as well when the htaccess file is removed - it works when everything is properly in place… on our server.

However, we haven’t had any luck when deploying to multiple client servers. They are all setup differently and getting it to work has been more trouble than it was worth.

I think some proper (tested) documentation on how to set it up and the removal of the file would be best. That said → it must work properly without it.

-Pieter

One trick on a server that actually accepts .htaccess is to rename the packaged files in the Release folder to .gz (ie, just move the dot right by two spaces).

We use IIS, so we have no need for the file anyway and its deleted by our build server. It would be nice if a standardized web.config was generated, otherwise, an option to not export this file would be good - it isn’t usable by everyone…

I’ve also had requests from my team to generate uncompressed files, which would be nice to be optional as well. If the file is going to be compressed for IIS, we’d much rather use dynamic compression and let the server compress it as required.

My two cents - when wrapping a WebGL package in such a way it isn’t a plain JS file (i.e. gzip) and knowing that it is intended to be used on different server configurations … then I’d highly recommend documenting very clearly what the expectations are for different server configurations - and what the expected configuration files and options look like.

Not trying to complain, but as it is, Unity in WebGL can be challenging. The many issues aside and focusing on builds for a moment … We’ve been finding the build structure & build options change between Unity versions. It is common for the options, settings and build changes to have no documentation. And I’ve been finding that fixed WebGL issues are often missing in the release notes. This is compounded by the fact there is no easy way to determine OS and Browser inside of the Unity blob itself … I’ve encountered plenty of WebPlayer and WebGL options that act very differently between platforms and browsers, it all comes together to make the process far more ā€œtrial and errorā€ than it probably should be - and reinforces the dangerous problems that the WebPlayer has been shielding us from.

1 Like

I had to add the mod_rewrite to Apache2 and also include the following two lines inside the .htaccess file:

  • AddType application/octet-stream .memgz .datagz .unity3dgz
  • AddType application/javascript .jsgz

Running fine now on Ubuntu 14.04/Apache2.

Hope it helps someone.

I get this same error but my game won’t load. Except on Internet Explorer (ironically). But it runs really slow on IE (not ironic at all). I tried Nightly, Firefox, Chrome, and Edge. I’m not sure if this is more of a server issue, browser issue, or OS/my laptop issue.

I tried two difference Apache Servers and I also got the blank screen with WebGL - Unity 5.3, despite the Docs saying it will just work!

However, I tried all of the above and nothing worked, but after wading through server error logs, the issue is with the htaccess file.

If you delete it, the gzip compression doesn’t happen and although everything works, the loading times are way longer. You do see the message in the javascript console that the Unity docs state.

With the htaccess file that Unity provides in the Release folder, and with the mime types added, it still didn’t work, even on an Apache Server.

HOWEVER, one of the server logs showedā€¦ā€œ.htaccess: Option FollowSymLinks not allowed hereā€

After some research, I replaced the +FollowSymLinks for +SymLinksIfOwnerMatch and everything works great even without the mime types added.

Hence, if someone from Unity could please tell me where to change this in the editor, so I do not have to manually edit the file after each upload, that would be just great.

I also tested firefox, chrome, safari, IE, and edge, all work great. Even Safari mobile worked (but very very slow).
But as yet, I haven’t figured out how to make Safari full screen. Any ideas?

Hope this helps others, cost me the best part of the day running trial and error, but I am happy that I now have a WebGL solution that works on a server.

Fwiw, they keep their template files in a subfolder in your Unity install. You can modify them so you aren’t stuck with a relatively hollow template. Just be aware changes here will be wiped out every Unity update.