On Fri, 2010-09-03 at 12:56 -0700, Paul McMillan wrote:
> I've only a small voice in this matter, but I'd like to chime in on
> the side of figuring out a way to solve this without requiring the
> Referer header.
>
> Regardless of what the RFC may say, I know from inspecting my logs
> that I (and
I've only a small voice in this matter, but I'd like to chime in on
the side of figuring out a way to solve this without requiring the
Referer header.
Regardless of what the RFC may say, I know from inspecting my logs
that I (and I assume many others) get a lot of traffic without the
header. The t
On Fri, 2010-09-03 at 17:26 +0100, Tom Evans wrote:
> On Fri, Sep 3, 2010 at 4:02 PM, Luke Plant wrote:
> > Hi Tom,
> >
> > On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
> >
> >> Any sort of Referer checking is broken by design, since that header is
> >> clearly optional. RFC 2616 makes expl
On Fri, Sep 3, 2010 at 4:02 PM, Luke Plant wrote:
> Hi Tom,
>
> On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
>
>> Any sort of Referer checking is broken by design, since that header is
>> clearly optional. RFC 2616 makes explicitly clear that applications
>> should not rely on Referer being
Hi Tom,
On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
> Any sort of Referer checking is broken by design, since that header is
> clearly optional. RFC 2616 makes explicitly clear that applications
> should not rely on Referer being sent. Any argument that sending it
> "is virtually never a
It is actually so that with using __future__ and >=2.6 you already have
most of the things available from Python 3 e.g. print() rather than
print. See table at the bottom of
http://docs.python.org/dev/library/__future__.html#module-__future__
Sure, everybody is raving about Python 3 but 2.6 bein
