New Content - Implemented Image path change due to new KoL hosting

With r16948 whatever it is that decorates the Mysterious Island of Mystery War-time side-quests with the red "F" is no longer working. I reverted to an earlier, chosen at random, r16764 release and the red "F"s reappeared. I'm guessing that it's related to the change in image servers.
 
By the way - for some reason, this screws up fonts or styles or something; every font is smaller, buttons don't look the same, and so on.

Darned if I can understand why this would be. I cleared my image cache and my browser cache, so everything is reloaded, but no joy.

I assume we are serving the wrong css file or something.

If anybody else who understands KoL's usage of css files is seeing this, I could use some help.

Thanks.
 
I'm not sure why, but core.js, cookies.whatever.js, and styles.whatever.css were garbage files when I cleared my cache. Looking into it.
 
Last edited:
gunzip decodes them. Looks like aws is sending them compressed (presumably we're specifying that we know how to decompress that?), and we're not decompressing them.
 
Okay. I think I understand. The browser says that it supports several encodings (gzip, deflate, sdch here). Looks like Mafia forwards this request. r16851 adds a temporary workaround that gunzips files before serving them to the browser.
 
Code: 
-----From Browser-----
GET /images/scripts/core.js HTTP/1.1
Host: 127.0.0.1:60080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.0.0.1:60080/topmenu.php
Connection: keep-alive
----------

Requesting: https://s3.amazonaws.com/images.kingdomofloathing.com/scripts/core.js
0 request properties

Retrieved: https://s3.amazonaws.com/images.kingdomofloathing.com/scripts/core.js
13 header fields
Field: null = [HTTP/1.1 200 OK]
Field: x-amz-meta-s3cmd-attrs = [uid:0/gname:asym_images/uname:root/gid:1000/mode:33204/mtime:1205288282/atime:1458845490/md5:45a04502549033f59a7820a3066bcc5c/ctime:1381342807]
Field: Server = [AmazonS3]
Field: Last-Modified = [Mon, 04 Apr 2016 22:53:29 GMT]
Field: Date = [Tue, 05 Apr 2016 13:16:28 GMT]
Field: Accept-Ranges = [bytes]
Field: Cache-Control = [public,max-age=31536000]
Field: ETag = ["144a28577e72a48ec67991facf6c941c"]
Field: Content-Encoding = [gzip]
Field: x-amz-request-id = [D64E6DA0D94F3974]
Field: Content-Length = [268]
Field: x-amz-id-2 = [xaYDd4AZi3qUsODV5jL7Fn7E3nf3IjCpuVZpmFmPwZ+WWcUgupvIGKQ9DdYrcq5tQIfqSUnrFJo=]
Field: Content-Type = [text/javascript]

-----To Browser-----
HTTP/1.1 200 OK
Date: Tue Apr 05 09:16:27 EDT 2016
Server: KoLmafia v17.2
Content-Type: text/javascript
Last-Modified: Mon, 04 Apr 2016 22:53:29 GMT
Connection: close
Hah. Thank you.

Seems like we could simply pass the Content-Encoding down to the the Browser.

Pondering.
 
Well, or not. Since we cache files we download from the image server, we'd have to remember that we were storing it encoded and then tell the browser next time we were giving it an encoded file.

Perhaps it would be simpler to just not forward the browser's Accept-Encoding header to KoL, just in case aws decides to encode in yet a different encoding we don't understand.

But in any case, your fix puts out the immediate fire - and makes the network traffic smaller, since the file is encoded.

Thank you!
 
Last edited:
Code: 
-----From Browser-----
GET /images/scripts/core.js HTTP/1.1
Accept-Encoding: gzip, deflate
----------
The browser said it would accept gzip.

Code: 
Requesting: https://s3.amazonaws.com/images.kingdomofloathing.com/scripts/core.js
0 request properties
We did not, in fact, pass that along.
Given your fix, we could set that ourself for any file.

Code: 
Retrieved: https://s3.amazonaws.com/images.kingdomofloathing.com/scripts/core.js
Field: Content-Encoding = [gzip]
Field: Content-Type = [text/javascript]
Amazon decided to gzip encode it anyway.

I think we need your fix regardless of what else we might do.
 
Veracity said:
The browser said it would accept gzip.

We did not, in fact, pass that along.
Given your fix, we could set that ourself for any file.

Amazon decided to gzip encode it anyway.
Click to expand...

That's actually pretty funny. I just assumed that Mafia forwarded the request to gzip files because I couldn't see why Amazon would violate the http standards so blatantly.

For what it's worth, Java seems like it also comes with a built-in InflaterInputStream, so with minimal effort, we could also support deflate if we wanted to.
 
It took me a while to realize why I still had some broken images showing up. They are all blank.gif, and r16803 prevents that image from being cached.
 
It looks like otherimages/blank.gif is 35 bytes, but itemimages/blank.gif is 61 bytes. That is an actual image, since currently if you try to load a bogus image URL on amazon you get an error page instead.
 
I see. Should we keep this in but add an explicit check for itemimages/blank.gif, or should we just remove it entirely? TPTB distinctly added that as a way to circumvent flooding the images server with requests to discover unknown images, and they are apparently aware of this new behavior.
 
So they intentionally send back blank.gif for unknown images?

I suppose we could save the 61 bytes of blank.gif and only save a 61 byte image that equals() that if we are explicitly fetching blank.gif.
 
Veracity said:
So they intentionally send back blank.gif for unknown images?

I suppose we could save the 61 bytes of blank.gif and only save a 61 byte image that equals() that if we are explicitly fetching blank.gif.
Click to expand...

This used to be the case (iirc, it was a response to cannon bruteforcing dv_weedskirt.gif to find the ZHA hard mode unlock) but stopped when TPTB migrated to Amazon's cloud; last I heard they were aware of this issue.
 
I just got a broken image when receiving the Agua de Vida Future quest reward:

Code: 
]*?(?:images.kingdomofloathing.com|/images)/itemimages/futurebox.gif" alt="secret from the future" title="secret from the future" class=hand onClick='descitem(502821529)'>	You acquire an item: secret from the future [use]

the html of choice.php should be attached to this reply.
 

Attachments

<img src=[^>]*?(?:images.kingdomofloathing.com|/images)/itemimages/futurebox.gif" alt="secret from the future" title="secret from the future" class=hand onClick='descitem(502821529)'>
Click to expand...

I wonder what that looked like before it was modified by mafia.
 
You must log in or register to reply here.
Back
Top