On Sat, 24 Jan 2004 00:04:06 +0000 Tom Barnes-Lawrence <tomble@usermail.com> wrote:
-I understand you not wanting the referer info being sent, even if it does make the logs from my hit-counter a bit less useful, *but*, some sites do seem to use the referer tags to work out if you're accessing their images, etc deep-linked from some other page. I'm afraid I can sort of sympathise with this, as the idea of "stealing bandwidth" does have quite a lot of truth in it (it does cost them money).
there is one important detail there that i think is very important: even if you want to avoid image linking by checking referers, you should allow EMPTY referers... that way: a) linking the images will still fail with the majority of browsers b) browsers that don't send referers will still work. c) users can for example post a link to a image on irc or whereever and the link will work (this is something that makes users like me really hate your site) d) users can use download programs to download files off the site without having to send fake referers (wget --referer, anybody?) (and to control those, there's robots.txt) imho not allowing the referer to be empty is just stupidity on the side of the people setting up the filtering, and it just makes their own problems worse, by forcing people to send fake referer headers (like my dillo does for QUITE some time now). (the patch is trivial, just add pairs of + "Referer: http://%s%s/\r\n" + URL_HOST(url), s_port->str, into src/IO/http.c (and don't get the order wrong))
So, I'd love it if the bookmarks code stuck each section in its own page, and let me nest one section in another. isn't this is kind of the point of seperating stuff into dpis?: if you don't like the default one, you can relatively easily change it without having to deal with the browser code or even recompile it.
Greetings, Thorben Thuermer