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

Magus_Prime · Apr 4, 2016

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.

Veracity · Apr 5, 2016

Revision 16849

Veracity · Apr 5, 2016

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.

heeheehee · Apr 5, 2016

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.

heeheehee · Apr 5, 2016

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.

heeheehee · Apr 5, 2016

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.

Veracity · Apr 5, 2016

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.

Veracity · Apr 5, 2016

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!

Veracity · Apr 5, 2016

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.

heeheehee · Apr 5, 2016

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.

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.

lostcalpolydude · Apr 7, 2016

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.

heeheehee · Apr 8, 2016

Actually, blank.gif is 35 bytes. r16803 stopped caching the garbage 61-byte response from the server.

lostcalpolydude · Apr 8, 2016

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.

heeheehee · Apr 8, 2016

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.

Veracity · Apr 8, 2016

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.

heeheehee · Apr 8, 2016

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.

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.

Malibu Stacey · Apr 11, 2016

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.

lostcalpolydude · Apr 11, 2016

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

I wonder what that looked like before it was modified by mafia.

Veracity · Apr 11, 2016

Oh, ha ha. I'll fix it.

Veracity · Apr 11, 2016

Revision 16876

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

Well-known member

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Active member

Attachments

Developer

Developer

Developer