On Mon, 2006-07-17 at 12:00 +0200, Michael Radziej wrote:
> Malcolm Tredinnick wrote:
> > On Sun, 2006-07-16 at 21:30 +0200, Michael Radziej wrote:
> >> I'm more for 'escaped' and 'raw', but not really violently. This is a
> >> minor issue, and I wouldn't like to get the work delayed by it.
> >> Also ... I volunteer to rewrite the docs if these terms change. But
> >> only once ;-)
> >
> > "Escaped" strikes me as bogus because it's not really the case: we are
> > just saying this output can be dumped in without further escaping.
>
> I see your point, you're right. But 'safe' still isn't necessary
> safe, I can perfectly mark unsafe strings as safe ;-)
Yeah. Btw, I can completely understand the flip side of this argument;
I'm partly just doing the Devil's Advocate thing so that things end up
on a solid foundation. You guys just need to invent a good name. I'll
write the code, you do the hard bit and come up with the
nomenclature. :-)
>
> > I thought about "raw" on Saturday and wondered if it would lead to
> > confusion: is a raw string "untreated" or "should not be treated
> > further" (we intend the latter).
>
> Interesting ... I was sure for everybody it meant the first one,
> along the line 'still needs cooking'. Wellllll ... seems not to work.
If you want to mark every "still needs cooking" string then you have to
mark *every* string that comes into the system (a la Perl's tainted
strings). The current method is to treat all strings as "untrusted" (or
requiring escaping) by default. Then we mark them when we have worked on
them. So the word you're looking for need to apply to "marked" strings,
not their former versions. (It's just too error-prone to try and catch
all strings on input and treat the ones we miss as safe.)
>
> I'd have lots of other ideas, but feel this is getting too far.
> How about brainstorming this on irc? Perhaps suggest a time that
> suits you.
I'll try to hang around on #django tomorrow if I don't get too busy.
But, seriously, just come up with some good names and make people pick
one. Stop letting people push back on your ideas and become The
Enforcer.
>
> >> I think so. Is there a case for escaping two times? I don't see any,
> >> and one could still easily craft a custom filter that does escape two
> >> times.
> >
> > Damn. Your phrasing tipped me off to a case we need this more: RSS feeds
> > and Atom content elements with type="html". :-(
>
> Hmm, really ... I've not been into RSS or Atoms, so I wasn't
> aware. I feel a little stupid about this, now. I assume that
> inside the <summary> element you have to escape html?
Only for type text="html" in Atom (which is Django's default production
method). There are a whole bunch of rules in the spec to accommodate
everybody from those who just can't get enough double-escaped markup in
their lives to those who want to use well-formed XML fragments to those
who want to shove raw bytes (base-64 encoded) in there. For RSS, things
are double-escaped everywhere as a matter of tradition.
> > We might need a "mark as unsafe" filter for these cases (so that {{ var|
> > escape|unsafe|escape }}) works (or just make "escape" not mark the
> > string as safe, but I suspect that will have unintended annoying
> > side-effects).
>
> Alternatively, you could add a filter that escapes 'safe' strings
> once and unsafe strings twice. Call it 'double_escape'. But this
> is a minor issue. I'm presently not sure what is better.
Again, I don't really care what the answer is here. I've thrown out some
ideas. People should propose better/different ones. This is very much a
non-religious issue for me beyond not wanting to sound stupid if/when I
stand up at a conference to give a tutorial on Django. So try to avoid
forming a consensus around calling the filter "elephant" or something,
ok? :-)
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
