This Gawker Thing

error

@Ben L. said:
The reason browsers can't fix that is that they don't KNOW if a URL is an image until they request it and parse the response.
WTF? OK, I know that I am stupid and insane but that's the craziest thing I ever heard of.
Website sends html to browser
Browser parses the html and sees <img src="some url.aspx">
Browser says "WHOA!! .aspx is not an image!! I'm not going to request that url!!"
You actually can't do that? My mind is blown once again.

Except some url.aspx was an image. Fail.

flabdablet

@El_Heffe said:

@Ben L. said:
The reason browsers can't fix that is that they don't KNOW if a URL is an image until they request it and parse the response.
WTF? OK, I know that I am stupid and insane but that's the craziest thing I ever heard of.
Website sends html to browser
Browser parses the html and sees <img src="some url.aspx">
Browser says "WHOA!! .aspx is not an image!! I'm not going to request that url!!"
You actually can't do that? My mind is blown once again.

The trouble is that .aspx?someparameter=somevalue quite often is an image, and having the browser make arbitrary judgements on what it thinks might turn up in the response headers to any given request is a rabbit hole you really don't want to go down.

The correct solution, as has been noted above, is for the server not to cause session state side effects on GET requests, which are the only kind an <img> tag can generate without help from Javascript. Community Server already does a reasonable job of filtering out js; I have yet to see anybody succeed in embedding arbitrary js in a post, comment or signature. Links included in <img> tags are the only way to cause drive-by HTTP requests here, so if CS were non-broken enough to do login/logout and similar state-affecting stuff only on POST, this attack would not be possible.

blakeyrat

@El_Heffe said:

Website sends html to browser
Browser parses the html and sees <img src="some url.aspx">
Browser says "WHOA!! .aspx is not an image!! I'm not going to request that url!!"

The browser has to at least request that URL's headers before it can tell if it's an image or not. You've never seen a URL like "http://somesite.com/images/imageserver.aspx?id=sda32hasd" before? They're pretty common.

In theory, the browser could request the headers, then if they turn out it actually is an image, make a second request to request the content. But that's not very efficient. And depending on how the page is coded, spitting out the headers might do the "logout" action anyway.

Zemm

@El_Heffe said:

Browser parses the html and sees <img src="some url.aspx">
Browser says "WHOA!! .aspx is not an image!! I'm not going to request that url!!"

La la la...

<img src="/users/avatar.aspx?userid=10318&lastmodified=635124161168932109" alt="" style="border-width:1px;border-style:solid;max-height:80px;max-width:80px;">

Lorne Kates

@El_Heffe said:

You actually can't do that? My mind is blown once again.

~~Though (and I may be wrong on this), if your browser requests an image, it isn't going to parse the cookies in that request~~

Well, just did a test page, and I was wrong about that. So not only would logout.aspx log you out server side, but yes it also expires your AUTH cookies. Wow.

blakeyrat

Wow. There's a lot of HTTP ignorance on display in this thread.

Lorne Kates

@blakeyrat said:

Wow. There's a lot of HTTP ignorance on display in this thread.

Yes, because every single one of us knows every single minutia of the protocol, so no one should ever discuss assumptions or run experiments, because it would be a waste of time to even THINK that there's something someone doesn't know. I mean, we can't all know the entire everything inside out like you [insert links to plethora of Blakeymistake joke here].

And Grog forbid someone should actually turn to a hivemind of their peers and admit "shit, I've never even thought about this, any of y'all?" [insert links to... you get it].

error

@Lorne Kates said:

@blakeyrat said:
Wow. There's a lot of HTTP ignorance on display in this thread.

Yes, because every single one of us knows every single minutia of the protocol, so no one should ever discuss assumptions or run experiments, because it would be a waste of time to even THINK that there's something someone doesn't know. I mean, we can't all know the entire everything inside out like you [insert links to plethora of Blakeymistake joke here].
And Grog forbid someone should actually turn to a hivemind of their peers and admit "shit, I've never even thought about this, any of y'all?" [insert links to... you get it].

It would be a WTF if it was web developers clueless about HTTP. It's deeply enough ingrained to us that we assume it to be common knowledge.

blakeyrat

Jesus. Relax. There's no negative connotation to the word "ignorance".

Lorne Kates

@blakeyrat said:

Jesus. Relax. There's no negative connotation to the word "ignorance".

Oh yeah:

ignorance

What do you say to that, Nancy?

blakeyrat

Look the real point is: if you feel insulted whenever some random idiot on the web calls you a wanker, or ignorant, or whatever, you're going to spend your entire life feeling insulted. Because you're such a wanker.

Only be insulted by people who actually know and respect. Anything else is just background noise.

error

@Lorne Kates said:

@blakeyrat said:
Jesus. Relax. There's no negative connotation to the word "ignorance".

Oh yeah:
ignorance

What do you say to that, Nancy?

Lorne Kates

@blakeyrat said:

Look the real point is: if you feel insulted whenever some random idiot on the web calls you a wanker, or ignorant, or whatever, you're going to spend your entire life feeling insulted.

You're assuming I'm insulted.

Snooder

@blakeyrat said:

Look the real point is: if you feel insulted whenever some random idiot on the web calls you a wanker, or ignorant, or whatever, you're going to spend your entire life feeling insulted. Because you're such a wanker.
Only be insulted by people who actually know and respect. Anything else is just background noise.

So? Choosing to ignore dicks on the internet doesn't make those people (i.e. YOU) any less of a dick. And responding to someone pointing out how much of a dick you are being with "stop being so sensitive" is like the height of dickishness.

@Lorne Kates said:

@blakeyrat said:
Jesus. Relax. There's no negative connotation to the word "ignorance".

Oh yeah:
ignorance
What do you say to that, Nancy?

Saturday

Lorne Kates

@El_Heffe said:

@Lorne Kates said:
@blakeyrat said:
Jesus. Relax. There's no negative connotation to the word "ignorance".

Oh yeah:
ignorance
What do you say to that, Nancy?
Saturday

You've ruined weekends for me. =(

flabdablet

@Snooder said:

the height of dickishness

Oh, my dick is much higher than yours.

@blakeyrat said:

@El_Heffe said:
Website sends html to browser
Browser parses the html and sees <img src="some url.aspx">
Browser says "WHOA!! .aspx is not an image!! I'm not going to request that url!!"

The browser has to at least request that URL's headers before it can tell if it's an image or not.

Yes, I know that. And to me, that's the crazy fucked up part. Essentially, the browser is saying "I'm going to trust the server to tell me what this file is . . what could possibly go wrong?" When I look at <img src="something.aspx"> it's pretty obvious that it's not an image. A browser should at least be that smart.@blakeyrat said:

You've never seen a URL like "http://somesite.com/images/imageserver.aspx?id=sda32hasd" before? They're pretty common.

Yes, but to me, that seems like something diffferent. You're passing parameters to imageserver.aspx, so that sort of makes sense. But <img src="imageserver.aspx"> makes no sense. It has become so common and standard "we have to request the URL's headers in order to know what the file is" that nobody even questions it any more, and that seems like a big WTF to me. Maybe it's because I'm not a web developer, so I can see that The Emporer Isn't Wearing Any Clothes. As an ignorant outsider it really seems like a case of "this is the way it's always been done, so it has to be OK".

blakeyrat

@El_Heffe said:

When I look at <img src="something.aspx"> it's pretty obvious that it's not an image.

Exercise 1: How do you know?

Exercise 2: Find something in the HTTP specification that supports your answer to exercise 1.

(Note that I've personally worked with, and rewritten from scratch, a system that serves up an image in response to a "something.aspx" call without any additional params. The only WTF there is that the file should have been named "something.ashx" if it followed the standard .net naming scheme.)

@El_Heffe said:

It has become so common and standard "we have to request the URL's headers in order to know what the file is" that nobody even questions it any more, and that seems like a big WTF to me.

Not as big as WTF as "referer".

I'm not sure I get your complaint honestly. How else could it possibly work? HTTP can't telepathically know what type of file it is without asking the server serving up the file-- it's technology, not magic.

Also the worst-case scenario is the browser sends a request to "something.aspx" and it turns out it's not an image, and the browser just shrugs and draws a broken image icon in the space. That's not that big a deal, is it? What's the negative result, other than the image doesn't render?

error

@flabdablet said:

Filed under: 8======================================================================D

If that's proportional, your penis has roughly the dimensions of an uncooked spaghetti noodle.

error

@blakeyrat said:

I'm not sure I get your complaint honestly. How else could it possibly work? HTTP can't telepathically know what type of file it is without asking the server serving up the file-- it's technology, not magic.

Also the worst-case scenario is the browser sends a request to "something.aspx" and it turns out it's not an image, and the browser just shrugs and draws a broken image icon in the space. That's not that big a deal, is it? What's the negative result, other than the image doesn't render?

He's thinking the web has file extensions. Which it does not.
Web servers might, but that's a shitty leaking implementation detail and good developers hide it with rewriting.

Lorne Kates

@El_Heffe said:

When I look at <img src="something.aspx"> it's pretty obvious that it's not an image. A browser should at least be that smart.

Here's the catch: around 2004, would you say <img src="something.png" /> was an image?

Or how about my own <img src="http://sevenseventeen.ca/xkcd.php" /> It's a PHP page that serves up a random image.

From a webdeveloper standpoint, it's easier for me to just let Apahce pass the request onto PHP, rather than writing a custom handler to look for xkcd.png and redirecting the request to PHP (rather than Apache's default "grab it from the file system").

And that's not even touching the 1.6 million other possible combinations of 4-character letters and number extensions that might or might not be an image.

Really the only way is for the browser to get the response, and ask "Can I parse this into an image".

error

@Lorne Kates said:

Really the only way is for the browser to get the response, and ask "Can I parse this into an image".

HTTP responses usually contain a Content-Type header, which will be eg "image/png". Actually, separating it into two parts, the generic kind-of-thing and the specific format, was really forward-thinking.

Edit: Browsers might plausibly send an Accept: image/* header for img tags, but enough braindead scripts exist that don't set this header that it would cause more issues than it solves.

blakeyrat

@joe.edwards said:

HTTP responses usually contain a Content-Type header, which will be eg "image/png". Actually, separating it into two parts, the generic kind-of-thing and the specific format, was really forward-thinking.

No it wasn't; MacOS did pretty much exactly that in 1984, except their system made more sense.

2) Considering they just kind of shit everything inside "application/X", they've made the entire top level kind of pointless. ("application/atom+xml"? But XML that isn't Atom is "text/xml". "application/json"? What does the word "application" mean exactly, "shit we couldn't fit somewhere else?")

error

@blakeyrat said:

What does the word "application" mean exactly, "shit we couldn't fit somewhere else?")

[quote user="RFC 2046"]

3. Overview Of The Initial Top-Level Media Types

The five discrete top-level media types are:

(1)   text -- textual information.  The subtype "plain" in
      particular indicates plain text containing no
      formatting commands or directives of any sort. Plain
      text is intended to be displayed "as-is". No special
      software is required to get the full meaning of the
      text, aside from support for the indicated character
      set. Other subtypes are to be used for enriched text in
      forms where application software may enhance the
      appearance of the text, but such software must not be
      required in order to get the general idea of the
      content.  Possible subtypes of "text" thus include any
      word processor format that can be read without
      resorting to software that understands the format.  In
      particular, formats that employ embeddded binary
      formatting information are not considered directly
      readable. A very simple and portable subtype,
      "richtext", was defined in RFC 1341, with a further
      revision in RFC 1896 under the name "enriched".

(2)   image -- image data.  "Image" requires a display device
      (such as a graphical display, a graphics printer, or a
      FAX machine) to view the information. An initial
      subtype is defined for the widely-used image format
      JPEG. .  subtypes are defined for two widely-used image
      formats, jpeg and gif.

(3)   audio -- audio data.  "Audio" requires an audio output
      device (such as a speaker or a telephone) to "display"
      the contents.  An initial subtype "basic" is defined in
      this document.

(4)   video -- video data.  "Video" requires the capability
      to display moving images, typically including
      specialized hardware and software.  An initial subtype
      "mpeg" is defined in this document.

(5)   application -- <span style="background: yellow; font-weight: bold">some other kind of data</span>, typically
      either uninterpreted binary data or information to be
      processed by an application.  The subtype "octet-
      stream" is to be used in the case of uninterpreted
      binary data, in which case the simplest recommended
      action is to offer to write the information into a file
      for the user.  The "PostScript" subtype is also defined
      for the transport of PostScript material.  Other
      expected uses for "application" include spreadsheets,
      data for mail-based scheduling systems, and languages
      for "active" (computational) messaging, and word
      processing formats that are not directly readable.
      Note that security considerations may exist for some
      types of application data, most notably
      "application/PostScript" and any form of active
      messaging.  These issues are discussed later in this
      document.

The two composite top-level media types are:

(1)   multipart -- data consisting of multiple entities of
      independent data types.  Four subtypes are initially
      defined, including the basic "mixed" subtype specifying
      a generic mixed set of parts, "alternative" for
      representing the same data in multiple formats,
      "parallel" for parts intended to be viewed
      simultaneously, and "digest" for multipart entities in
      which each part has a default type of "message/rfc822".

(2)   message -- an encapsulated message.  A body of media
      type "message" is itself all or a portion of some kind
      of message object.  Such objects may or may not in turn
      contain other entities.  The "rfc822" subtype is used
      when the encapsulated content is itself an RFC 822
      message.  The "partial" subtype is defined for partial
      RFC 822 messages, to permit the fragmented transmission
      of bodies that are thought to be too large to be passed
      through transport facilities in one piece.  Another
      subtype, "external-body", is defined for specifying
      large bodies by reference to an external data source.

It should be noted that the list of media type values given here may
be augmented in time, via the mechanisms described above, and that
the set of subtypes is expected to grow substantially.

[/quote]

HardwareGeek

@blakeyrat said:

2) Considering they just kind of shit everything inside "application/X", they've made the entire top level kind of pointless. ("application/atom+xml"? But XML that isn't Atom is "text/xml". "application/json"? What does the word "application" mean exactly, "shit we couldn't fit somewhere else?")

I think so. My favorite is definitely application/octet-stream. It nails down the content type so precisely.

blakeyrat

@joe.edwards said:

[quote user="RFC 2046"]

3. Overview Of The Initial Top-Level Media Types
The five discrete top-level media types are:

blah blah blah

[/quote]

The point/question is:

Why is XML data "application" when it describes ATOM feeds, but "text" when it describes something else?

ender

@El_Heffe said:

When I look at <img src="something.aspx"> it's pretty obvious that it's not an image.

Hey, look, this obviously isn't an image:
...or is it?

error

@blakeyrat said:

@joe.edwards said:
[quote user="RFC 2046"]

3. Overview Of The Initial Top-Level Media Types
The five discrete top-level media types are:

blah blah blah

The point/question is:

Why is XML data "application" when it describes ATOM feeds, but "text" when it describes something else?

[/quote] [quote user="RFC 2023"]

If an XML document -- that is, the unprocessed, source XML document -- is readable by casual users, text/xml is preferable to application/xml. MIME user agents (and web user agents) that do not have explicit support for text/xml will treat it as text/plain, for example, by displaying the XML MIME entity as plain text. Application/xml is preferable when the XML MIME entity is unreadable by casual users. Similarly, text/xml-external-parsed-entity is preferable when an external parsed entity is readable by casual users, but application/xml-external-parsed-entity is preferable when a plain text display is inappropriate.

  NOTE: Users are in general not used to text containing tags such
  as &lt;price>, and often find such tags quite disorienting or
  annoying.  If one is not sure, the conservative principle would
  suggest using application/* instead of text/* so as not to put
  information in front of users that they will quite likely not
  understand.

[/quote]

blakeyrat

Damn you and your answering my questions!

Ronald

@El_Heffe said:

It has become so common and standard "we have to request the URL's headers in order to know what the file is" that nobody even questions it any more, and that seems like a big WTF to me. Maybe it's because I'm not a web developer, so I can see that The Emporer Isn't Wearing Any Clothes. As an ignorant outsider it really seems like a case of "this is the way it's always been done, so it has to be OK".

Here is an example. To give the impression that the website is faster, a client wants the pictures on his website to be progressive jpeg (at 10% download a progressive jpeg is clear enough to have a nice picture, while a non-progressive jpeg is only a small slice that shows 10% of the image - see this example). You could get the same effect with an interlaced png but it's a lot more painful on the bandwidth.

However some people use a retarded browser that does not support progressive jpeg (like IE8 or Safari) so for those people the client wants to fallback on interlaced png rather than dump a baseline jpeg. So what a developer could do if he does not want to maintain two versions of every image is have the webserver intercept the image requests, load the image from his file system (or CDN), convert it to the right format and send it back after setting the right content type.

Of course you could choose to put a ".jpg" extension so from the client it looks like you are downloading a jpg, but if you want the same extension for both the retarded and decent browsers (so people can send links to each other) you will end up lying on the actual content. There is a library that will intercept all images extension to do this kind of magic (and you can add a querystring to alter the image, change the size, etc) but it's still lying. So why bother.

HardwareGeek

@Ronald said:

However some people use a retarded browser that does not support progressive jpeg (like IE8 or Safari)

TRWTF is that such browsers still exist in 2013.

dhromed

@Ronald said:

a client wants the pictures on his website to be progressive jpeg (at 10% download a progressive jpeg is clear enough to have a nice picture, while a non-progressive jpeg is only a small slice that shows 10% of the image - see this example).

It's difficult to imagine why someone would fabricate these rendering speeds for an 80KB jpeg, which was instantaneous 10 years ago.

Only under very bad server conditions have I experienced that kind of display sluggishness in recent times.

dkf

@HardwareGeek said:

My favorite is definitely application/octet-stream. It nails down the content type so precisely.

It's just the server saying “Shit, I dunno what this is. Here, have the bytes.” Sometimes, that's the best it can do, and it definitely beats refusing to serve the data altogether.

beginner_

@joe.edwards said:

At my job, passwords expire every 60 days, and you don't get to make them up. There's a web interface that shows you a list of equally meaningless jumbles of letters and numbers and you have to pick one off the list.

That sounds retarded. Personalyl I think this makes it less secure becasue 90% of people will then write it on a post-it and stick it to the display. So you should better let them choose a password they can actually remember. IMHO the easiest thing would be fingerprint scanners...and if your paranoid in combination with a stable, user choosable password.

@joe.edwards said:

Gosh, his real name? You guys will never figure mine out.

My guess is googling for joe edwards will return 99% od stuff that is some other guy with the same name. In my case, my real name is very rare (possibly I'm the only one) and all the stuff you find is from me. meaning it matters what your name is. In soem way you are still pretty anonymous.

Ronald

@dhromed said:

@Ronald said:
a client wants the pictures on his website to be progressive jpeg (at 10% download a progressive jpeg is clear enough to have a nice picture, while a non-progressive jpeg is only a small slice that shows 10% of the image - see this example).
It's difficult to imagine why someone would fabricate these rendering speeds for an 80KB jpeg, which was instantaneous 10 years ago.
Only under very bad server conditions have I experienced that kind of display sluggishness in recent times.

Servers have nothing to do with it, unless you want to force users to come see the webpage in the server room (aka: the 1-tier architecture).

Ronald

@beginner_ said:

IMHO the easiest thing would be fingerprint scanners...and if your paranoid in combination with a stable, user choosable password.

Fingerprint are a terrible choice for authentication. Skin condition, angle, need to maintain multiple fingers signatures per user, etc. Ask anybody who ever used it on a Thinkpad, it really is a piece of shit and only lead to a disgusting oily patch in the scanner area.

The best solution at the moment for biometrics is hand vascular scanners (no physical contact is needed) but this is not convenient for a laptop or even desktop. Passwords or SmartCards still win.

dhromed

@Ronald said:

Servers have nothing to do with it,

Since internet has quite a lot to do with servers, I think we're under the false impression of a misunderstood miscommunication.

I'm saying that progressive jpegs are obsolete, since images appear on your screen pretty much instantly. Unless the infrastructure can't deal with the load, but real sluggishness of the kind in the video you linked is very rare.

Ronald

@dhromed said:

@Ronald said:
Servers have nothing to do with it,

Since internet has quite a lot to do with servers, I think we're under the false impression of a misunderstood miscommunication.
I'm saying that progressive jpegs are obsolete, since images appear on your screen pretty much instantly. Unless the infrastructure can't deal with the load, but real sluggishness of the kind in the video you linked is very rare.

If you do a Google Image search for "beautiful wallpaper" and you click on one of the big ones, you will see a progressive jpeg in action (plus the small endless spinner at the bottom of the picture until it's 100%). Of course all it means is that Google does not understand internet as well as you do.

ender

@dhromed said:

I'm saying that progressive jpegs are obsolete, since images appear on your screen pretty much instantly.

Progressive JPEGs are usually smaller than non-progressive ones. Depending on the image size and how much traffic you get, this can be significant.

dhromed

@Ronald said:

If you do a Google Image search for "beautiful wallpaper" and you click on one of the big ones, you will see a progressive jpeg in action (plus the small endless spinner at the bottom of the picture until it's 100%).

That's not a progressive jpeg in action. It's a small thumbnail stored at google, which is displayed instantly while it fetches the actual image. You never see the actual image loading. The thumbnail has the typical blurry look of a progressive jpeg because it's upscaled to fit the space.

The real picture (which is significantly big at 4.8 MB), when loaded in a different browser (because I didn't feel like clearing cache) is a non-progressive*, and yeah, at my work's subpar internet it visibly loads top to bottom. I'd have to try it at home to see if it's that slow. Got bigger pipes there.

Clearly the set of situations where a progressive jpeg is preferrable is bigger than I imagined.

NEXT TIME, GADGET, NEXT TIME.

HardwareGeek

@dkf said:

@HardwareGeek said:
My favorite is definitely application/octet-stream. It nails down the content type so precisely.
It's just the server saying “Shit, I dunno what this is. Here, have the bytes.” Sometimes, that's the best it can do, and it definitely beats refusing to serve the data altogether.

Sure, but maybe the person that put the data there, or the application that generates it could, I dunno, maybe, tell the sever what kind of data it is. There really isn't an excuse for using it where a suitable type/subtype is defined.

dkf

@HardwareGeek said:

Sure, but maybe the person that put the data there, or the application that generates it could, I dunno, maybe, tell the sever what kind of data it is. There really isn't an excuse for using it where a suitable type/subtype is defined.

That would be nice, especially if they were guaranteed to be telling the truth. Doesn't happen nearly as often as you'd like. Code gets the type wrong. People tell lies about the type (not always maliciously either). Sometimes you've just got to work with what you've got.

anonymous235

@HardwareGeek said:

My favorite is definitely application/octet-stream. It nails down the content type so precisely.

Well, it tells you how many bits the server is using. You never know when you can find a septet or nonet stream.

OldCrow

@dhromed said:

Clearly the set of situations where a progressive jpeg is preferrable is bigger than I imagined.

It gets even bigger when you remember that some parts of the third world only have modem coverage if even that. And at least a third of the U.S., from what I hear.

80KBytes / 56Kbits/s = 11+ seconds

Ronald

@anonymous235 said:

@HardwareGeek said:
My favorite is definitely application/octet-stream. It nails down the content type so precisely.

Well, it tells you how many bits the server is using. You never know when you can find a septet or nonet stream.

That's why I prefer to keep things less strict and use

application/force-download

HardwareGeek

@anonymous235 said:

@HardwareGeek said:
My favorite is definitely application/octet-stream. It nails down the content type so precisely.

Well, it tells you how many bits the server is using. You never know when you can find a septet or nonet stream.

nonet stream

dkf

@OldCrow said:

It gets even bigger when you remember that some parts of the third world only have modem coverage if even that. And at least a third of the U.S., from what I hear.
80KBytes / 56Kbits/s = 11+ seconds

You also have to allow for additional bandwidth being taken up with overhead (e.g., packet headers). That 11 seconds is definitely an aggressive lower bound on the transfer time (especially as images are usually hard to compress further, unlike text).

Or you can just say fuck it and code for people who aren't in the (virtual) boonies.

dhromed

@dkf said:

Or you can just say fuck it and code for people who aren't in the (virtual) boonies.

But that will exclude most Americans!

locallunatic

@dhromed said:

@dkf said:
Or you can just say fuck it and code for people who aren't in the (virtual) boonies.

But that will exclude most Americans!

Actually having to deal with my countrymen, wouldn't that be a plus?