java4k.com website is down

Contests 4K Game Competition - 2013
#21

This is realllllllly retarded.

I’m getting “Incompatible magic value 1008813135 in …” error on almost every applet. No idea what is causing this.

After some googling it says that the "1008813135 " value translates into “<!DO”. Which is strange, because the applets that are being sent from the new host are identical to the ones on the old host, I compared them with the original copies that I have verified and no difference.

Either this is only at my end or something is really fubar with java applets (wouldn’t be the first!).

Anyone let me know if they can find out what’s going on?

#22

wget to the rescue

#23

A quick search showed that clearing the java cache can solve this specific issue.

So: Go to Java Control Panel, “General” tab, and under “Temporary Internet Files” click “Settings”, then click “Delete Files”

Mike

#24

You’re probably not sending the right http headers… given that ‘almost every applet’ crashes (pack200) and some apparently work (jars).

#25

Wow that is weird. Are you sure the server sends the class files properly without modification on the way?

#26

wget to the rescue

#27

A quick search showed that clearing the java cache can solve this specific issue.

So: Go to Java Control Panel, “General” tab, and under “Temporary Internet Files” click “Settings”, then click “Delete Files”

Mike

#28

It should be sending the same headers, as its the same script.

Here’s my result:

C:\Program Files (x86)\GnuWin32\bin>wget --server-response http://www.java4k.com
/applet.php?gid=448
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
–2013-06-18 21:07:58-- http://www.java4k.com/applet.php?gid=448
Resolving www.java4k.com… 31.170.162.194
Connecting to www.java4k.com|31.170.162.194|:80… connected.
HTTP request sent, awaiting response…
HTTP/1.1 200 OK
Date: Tue, 18 Jun 2013 21:08:02 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: PHPSESSID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; path=/
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Encoding: pack200-gzip
Content-Disposition: attachment; filename=flywrench4k.kz.pack.gz
Content-Transfer-Encoding: binary
Content-Length: 4079
Connection: close
Content-Type: application/x-java-pack200; name=“flywrench4k.kz.pack.gz”
Length: 4079 (4,0K) [application/x-java-pack200]
Saving to: `applet.php@gid=448.2’

100%[======================================>] 4.079 --.-K/s in 0s

2013-06-18 21:07:59 (125 MB/s) - `applet.php@gid=448.2’ saved [4079/4079]

C:\Program Files (x86)\GnuWin32\bin>

#29

You’re probably not sending the right http headers… given that ‘almost every applet’ crashes (pack200) and some apparently work (jars).

#30

Then check the actual data transfer with a tool like WireShark.

#31

It should be sending the same headers, as its the same script.

Here’s my result:

C:\Program Files (x86)\GnuWin32\bin>wget --server-response http://www.java4k.com
/applet.php?gid=448
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
–2013-06-18 21:07:58-- http://www.java4k.com/applet.php?gid=448
Resolving www.java4k.com… 31.170.162.194
Connecting to www.java4k.com|31.170.162.194|:80… connected.
HTTP request sent, awaiting response…
HTTP/1.1 200 OK
Date: Tue, 18 Jun 2013 21:08:02 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: PHPSESSID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; path=/
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Encoding: pack200-gzip
Content-Disposition: attachment; filename=flywrench4k.kz.pack.gz
Content-Transfer-Encoding: binary
Content-Length: 4079
Connection: close
Content-Type: application/x-java-pack200; name=“flywrench4k.kz.pack.gz”
Length: 4079 (4,0K) [application/x-java-pack200]
Saving to: `applet.php@gid=448.2’

100%[======================================>] 4.079 --.-K/s in 0s

2013-06-18 21:07:59 (125 MB/s) - `applet.php@gid=448.2’ saved [4079/4079]

C:\Program Files (x86)\GnuWin32\bin>

#32

Then check the actual data transfer with a tool like WireShark.

#33

From old server that worked:

HTTP/1.1 200 OK
Date: Tue, 18 Jun 2013 21:58:37 GMT
Server: Apache/2.2.21 (Win64) PHP/5.3.10
X-Powered-By: PHP/5.3.10
Set-Cookie: PHPSESSID=qqct18g16c60l3hqqbbtrlb3m6; path=/
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Encoding: pack200-gzip
Content-Disposition: attachment; filename=flywrench4k.kz.pack.gz
Content-Transfer-Encoding: binary
Content-Length: 4079
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/x-java-pack200; name=“flywrench4k.kz.pack.gz”
Length: 4079 (4,0K) [application/x-java-pack200]
Saving to: `applet.php@gid=448.2’

From new server:

HTTP/1.1 200 OK
Date: Tue, 18 Jun 2013 22:00:33 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: PHPSESSID=0a164569ce9efb0e9818a1e721f523dd; path=/
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Encoding: pack200-gzip
Content-Disposition: attachment; filename=flywrench4k.kz.pack.gz
Content-Transfer-Encoding: binary
Content-Length: 4079
Connection: Keep-Alive, close
Keep-Alive: timeout=5, max=100
Content-Type: application/x-java-pack200; name=“flywrench4k.kz.pack.gz”
Length: 4079 (4,0K) [application/x-java-pack200]
Saving to: `applet.php@gid=448.4’

I compared the two outputs, and both are identical.

I’m going insane!!! Either there’s something wrong with java applets or there’s something wrong with java applets.

Btw, the game I’m trying to run is this:
http://www.java4k.com/index.php?action=games&method=view&gid=448
Let me know if it works at your end. If it does, that means I’ll have to buy a new hard disk to wipe that stupid applet cache.

#34

From old server that worked:

HTTP/1.1 200 OK
Date: Tue, 18 Jun 2013 21:58:37 GMT
Server: Apache/2.2.21 (Win64) PHP/5.3.10
X-Powered-By: PHP/5.3.10
Set-Cookie: PHPSESSID=qqct18g16c60l3hqqbbtrlb3m6; path=/
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Encoding: pack200-gzip
Content-Disposition: attachment; filename=flywrench4k.kz.pack.gz
Content-Transfer-Encoding: binary
Content-Length: 4079
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/x-java-pack200; name=“flywrench4k.kz.pack.gz”
Length: 4079 (4,0K) [application/x-java-pack200]
Saving to: `applet.php@gid=448.2’

From new server:

HTTP/1.1 200 OK
Date: Tue, 18 Jun 2013 22:00:33 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: PHPSESSID=0a164569ce9efb0e9818a1e721f523dd; path=/
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Encoding: pack200-gzip
Content-Disposition: attachment; filename=flywrench4k.kz.pack.gz
Content-Transfer-Encoding: binary
Content-Length: 4079
Connection: Keep-Alive, close
Keep-Alive: timeout=5, max=100
Content-Type: application/x-java-pack200; name=“flywrench4k.kz.pack.gz”
Length: 4079 (4,0K) [application/x-java-pack200]
Saving to: `applet.php@gid=448.4’

I compared the two outputs, and both are identical.

I’m going insane!!! Either there’s something wrong with java applets or there’s something wrong with java applets.

Btw, the game I’m trying to run is this:
http://www.java4k.com/index.php?action=games&method=view&gid=448
Let me know if it works at your end. If it does, that means I’ll have to buy a new hard disk to wipe that stupid applet cache.

#35

Now try wireshark to see what the java plugin actually receives.

#36

Now try wireshark to see what the java plugin actually receives.

#37

Can’t help you there. Like any sane person I disabled the Java plugin :slight_smile:

#38

Can’t help you there. Like any sane person I disabled the Java plugin :slight_smile:

#39

Yea, I should have done that initially. I found the problem, the java plugin is doing get on this:
GET /applet.php.pack.gz?gid=448

when it should be doing get on this:
GET /applet.php?gid=448

It is appending that “.pack.gz” to the url.

Here’s the applet object code:

<object code="F.class" archive="applet.php?gid=448" width="800" height="600" type="application/x-java-applet;version=1.5">
<param name="java_arguments" value="-Djnlp.packEnabled=true" />
<param name="cache_option" value="no">
</object>

So… another question why does this work differently between servers?

#40

had to be set to:

Makes sense?

ANYWAY… all fixed now… darn tough to figure this out. Applets are clearly not very portable, and the deployment procedure is an annoying pain.