Wedge

I'd rather not, to be honest. The likelihood is that if it's failed getting it from 16K (or 32K), it's probably a big file, which means the original code is going to have to retrieve the entire file which on any host with low settings is going to cause a white screen.

I'd rather go to a 32K buffer than have to hit the server a second time (though the code had a habit of making two requests so even if we did a 16K hit generally and a further 64K hit if it's JPEG and we didn't find it in the first 16K, that would probably not be a killer.If it's broken, it's broken, no matter how big the buffer is. There's only any point doing a retry if you can theoretically get some mileage out of it; I wouldn't have it retry on images that show up as PNG or GIF, or things that don't flag up as JPG.

That said, the current code can be refined. Right now it assumes a range will be provided, of up to 16K - but support of ranges is not required (though strongly recommended) in HTTP/1.1 servers, and if the server ends up throwing a large JPG at the user, it's going to step through the file looking at the boundaries. Consequently, if the file is bigger than the specified range, we can legitimately assume it's the whole file, rather than a ranged subset, and apply getimagesize on it.

Revision: 1124
Author: arantor
Date: 02:05:35, 20 October 2011
Message:
! Stupid, stupid syntax error where I wasn't developing directly on the SVN files, and forgot to copy all the changes across properly. (Subs.php)
----
Modified : /trunk/Sources/Subs.php

After a day of swearing and wrangling I've got something I'm reasonably happy with, but I'm not quite as happy as I could be.

GIF and PNG work well enough, they only need the first dozen bytes or so but JPEG is a pain because the header is not necessarily where you expect it to be. Plans of just grabbing the first KB went out the window as soon as I started investigating JPEGs, I bumped it to 8KB pretty quickly, and I'm currently working on 16KB.

Still, downloading 16KB to determine file size isn't bad. Of the 15364 files tested with either .jpg or .jpeg extension on my PC, 15039 were able to have their file sizes detected to be the same as what getimagesize returns. Of the 325 remaining, there are a number that are damaged files anyway (recoveries from old HDs and so on) and the rest, pretty much unilaterally, have the relevant marker block after the 16KB boundary. Larger files (even 512x512) sometimes have the boundary at 20KB into the file.[1]

So at this point I'm playing the game of diminishing returns, I can either up the boundary and accept the inevitable loss of performance or I can cut my losses.

Hmm, let's run some stats and get a proper handle on the state of play.
* 16KB: matches 15039 out of 15364 (97.8%)
* 32KB: matches 15246 out of 15364 (99.2%)
* 64KB: matches 15284 out of 15364 (99.5%)

Of the 80 that couldn't be matched at 64K, only 3 weren't corrupted, and they're ones that are special, using CMYK colour separation, so that some browsers don't render them properly anyway.

So we're really looking at 15287 files not 15364 here, which puts the percentages at:
16K: 98.4%
32K: 99.7%
64K: 99.9%

I think I'm going to call it a day here and commit things with the 16K version; we can always bump it up to 32K (or provide instructions) if need be.

1.

Just consider this for a moment. We're talking JPG. It's not layered, not transparent, doesn't have multiple 'images' inside, and yet we have 20KB of stuff before we get to set out the *size* of the image. Funnily enough I can tell you exactly what tools cause that, and one company in particular... :whistle: I'll leave you to guess which company.

I'm still waiting for guidance on how the notion of opt-in for cookies is supposed to work given the changes in the spring about it, again another fine mess of being seen to be tackling problems without understanding the problem or the consequences of the "fix".

Herein lies the problem: I could wake up one morning to find my host had received a request overnight to shut down a site, without prior warning. At least a lawsuit can be contested, whereas such a request theoretically might not be able to - if the host is suspended, under the terms of suspension it may not always be possible for a site operator to get it unsuspended, if say access to the CMS is tied to domain name and the entire domain is taken down, unless the host is willing to do the work for you or otherwise help you, you're stuffed.

Also note that while the focus is anonymous posters, the term 'anonymous' is incredibly vague these days where everyone can create a new pseudonym with about as much anonymity as would be possible - in everything but name, really.

Have a read of http://www.theregister.co.uk/2011/10/19/proposals_on_defamation_law/

It has interesting consequences for us (well, me in particular :P)

I think the whole anonymous thing is going to bite people in the arse before long, personally, but one thing I do find interesting is the notion of publishing a complaint next to a post itself. That essentially means publishing the report-to-moderator stuff as freely as regular posting. I see two problems with this.

Firstly, it seems to me that the complainant will have to identify themselves, which if I were to - say - report a post because I find it offensive, I'm essentially telling the world that I personally have a problem with a post. While that's not a great example, imagine a forum with more sensitive discussions, e.g. personal abuse support. I certainly wouldn't want my name attached to a publicly-visible complaint.

Secondly, can we say spam magnet? Posts can be moderated but complaints don't appear to be such.

Sure, we can indicate 'type of complaint', such that personal complaints don't need to be made public and can be restricted to intra-forum matters, e.g. reporting spam, personal offence, and leave libel ones public. But that won't solve the spam bot problem, since they'll just learn to select 'libel' to have their crap posted publicly.


Thoughts?

Oh yeah, had THAT a lot. At least when I criticise something I try to have a reason why I think it is the way it is...