Image fail



  • Ugh - my eyes hurt now. "view source" reveals that most of this 600kB behemoth of a page is a single image tag with the image content base-64-encoded and embedded directly. Way to defeat cacheing and kill my bandwidth, guys.



  • @Julia said:

    most of this 600kB behemoth of a page is a single image tag with the image content base-64-encoded and embedded directly
    No Repro. Looks like a bog-standard webpage from here.



  • @Julia said:

    "view source" reveals that most of this 600kB behemoth of a page is a single image tag with the image content base-64-encoded and embedded directly. Way to defeat cacheing and kill my bandwidth, guys.

    Bonus points for being an image that doesn't work.



  • Fixing the hilariously encoded characters in the source gives this image:



  • @PJH said:

    @Julia said:
    most of this 600kB behemoth of a page is a single image tag with the image content base-64-encoded and embedded directly
    No Repro. Looks like a bog-standard webpage from here.
    No repro here either. Is this perhaps one of those things I would need to disable Adblock Plus and/or NoScript to understand?



  • @Salamander said:

    @Julia said:
    "view source" reveals that most of this 600kB behemoth of a page is a single image tag with the image content base-64-encoded and embedded directly. Way to defeat cacheing and kill my bandwidth, guys.

    Bonus points for being an image that doesn't work.

    You can't really use the document inspector to see broken HTML. It "fixes" certain things, like missing quotation marks. To see the real HTML you have to view the source.



  • <span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;">



  • @Ben L. said:

    <span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;"><span style="color: #000000;">

    You're mixing style and data information in static HTML? Good lord man!



    What's needed here is an AJAX call to a server which returns the image data encoded in JSON, and a jQuery widget which renders the data onto an HTML5 Canvas (converting to web-safe colors as required). WebGL surfaces instead of a Canvas will be put in the Epic for phase 2.



  • Ah! Repro now. Thanks for the screenshot with the line number in it, I had given up before scrolling that far down.

    Looks like the typically broken result of trying to paste a clipboard image straight into a WYSIWYG edit control; the PrtSc that filled up the clipboard was most likely unintentional. Which would make McAfee TRWTF, for causing the author's system to be so characteristically unresponsive that they didn't even notice the delay from 600K of unexpected upload.

    The smartified quotes were nifty, but I particularly enjoyed the single "x" randomly replaced with an &215; entity code (Unicode multiplication sign) in the middle of all that base64. Gotta love "smart" edit controls.

    Edit: probably not random, just the only instance of an x with digits either side.



  • @flabdablet said:

    Ah! Repro now. Thanks for the screenshot with the line number in it, I had given up before scrolling that far down.
    I scrolled fast and looked for a huge chunk of base64. OP did say "most of" the page; I figured you can hardly miss it if you go that route.@flabdablet said:
    The smartified quotes were nifty, but I particularly enjoyed the single "x" randomly replaced with an &215; entity code (Unicode multiplication sign) in the middle of all that base64. Gotta love "smart" edit controls.
    You found that? I'm impressed. I gave up when I got the complaint about invalid base64 characters. Although I guess it would've been easy enough to find, if the base64 decoder would've said that "&" was the invalid character instead of just balking.



  • @anotherusername said:

    OP did say "most of" the page; I figured you can hardly miss it if you go that route.
    First few times I did in fact miss it. Surprisingly easy to do if "wrap long lines" isn't turned on in the page source viewer.

    @anotherusername said:

    You found that? I'm impressed. I gave up when I got the complaint about invalid base64 characters.
    Regex search for [^A-Za-z0-9/+]] did the job. By the time &215; had made it through the clipboard into the text editor, it had been transmuted to %C3%97 (still trying to work out the rationale for that one).



  • @flabdablet said:

    Regex search for [^A-Za-z0-9/+]] did the job. By the time &215; had made it through the clipboard into the text editor, it had been transmuted to %C3%97 (still trying to work out the rationale for that one).
    If you right-click and "Copy Link Location", it converts HTML entities to their respective characters (&#215; to ×) and URL-encodes the whole thing. Also slaps http://www.teachersatrisk.com/ at the beginning, since it thinks it is a relative URL



  • Yeah, that's what I did and that's what it did, but I still don't quite understand how the multiply sign (Unicode code point U+00D7) ended up encoded as %C3%97. The process makes sense to me, but the actual values encoded remain elusive.



  • @flabdablet said:

    Yeah, that's what I did and that's what it did, but I still don't quite understand how the multiply sign (Unicode code point U+00D7) ended up encoded as %C3%97. The process makes sense to me, but the actual values encoded remain elusive.

    UTF-8, that's how. Code points of 7 bits (or fewer) can be encoded as a single byte, which is prefixed with 0. Larger code points are broken up into chunks of 6 or fewer bits, which are prefixed to 8 bits and always start with 1, indicating a multi-byte sequence. The first byte's prefix indicates how many bytes are in the sequence (for a 2-byte sequence, it's two ones followed by zero, 110); subsequent bytes are all prefixed with 10. So a 1-byte character will look like 0xxxxxxx; a 2-byte sequence like 110xxxxx 10xxxxxx; a 3-byte sequence like 1110xxxx 10xxxxxx 10xxxxxx; etc. (using red to indicate the prefixes).

    00D716 = 00011 0101112 (11 bits, broken into bits 10-6 and bits 5-0)

    The byte prefixes are added as required for a 2-byte code point in UTF-8:

    110000112 100101112 = C316 9716



  • I thought I had already checked that and found it to be an invalid encoding. Dropped a bit during a brain fart, I guess. Thanks.



  • </html> tags found in the page: 5


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.