Hacker News Reader

Comment by eqvinox | Hacker News Reader

Well, I mean, they're presumably also keeping all of the messages you ever sent (for "quality assurance" purposes of course), so the privacy aspect certainly can't be the point of contention here.

The bandwidth usage on the other hand is a different question, this essentially allows a reflection-style DoS against any HTTP server hosting large-ish files. Presumably you can stick nonsense query parameters after the URL just to create distinct URLs for the single largest file you found?

View on HN

This got me wondering. Is there any native way to HTTP to get a checksum or some hash of a file at the beginning of a transfer?

Isn't that part of the point of etag headers?

Thanks for the name. I looked it up and it seems close. But I think it's up to the client to provide an etag and the server to respond with the same etag and a 304.

What I'm thinking is a server blind way for the client to say: "give me th resource at address X. ... Oh you know what i think I already have this one. Let's abort the transfer."

I guess what I'm thinking is a way for th client to decide it's a 304, not the server.

The If-Match and If-None-Match headers makes the request conditional. You can also of course store the etag with the file or calculate the checksum and do a HEAD conditionally followed by a GET. But there isn’t any advantage to that over If-Match

Wouldn’t that create a giant mess if someone forged the header etag to match something else?

I haven't got enough skin in this to read any RFCs but my assumption had been it's not intended to act as a point of truth or verify contents and was always only to be used in an advisory capacity. So yeah, it would cause a mess.

Yeah I think it's meant to be used in a context of mutual trust.

Download the first 1mb and hash that? Or intermediate portions if the server supports resuming?

That's a clever but fatally flawed solution given how many files could share the first MB.

Reply on news.ycombinator.com