Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postel’s Principle is a Bad Idea

programmingisterrible.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Postel’s Principle is a Bad Idea

#51

Post by [deleted] »

DougBTX wrote: post #45
colomon wrote: post #23

Earlier quoted context omitted.

But this is where "be conservative in what you do" comes into play. The STEP format has formal rules for exporting all ASCII, Unicode, and ISO-8859 characters. A well-written STEP string exporter should handle them all without difficulty, no matter what goofy things are in the string. And again, if you're worried that there may be an attack vector, change high-bit-set characters to "[Illegal character value N]". Thou…

The tl;dr of the article is to define handling of invalid input, so that all conforming implementations will handle it in the same way, without having to reverse-engeneer eachother to be interoperable.

[deleted]

Re: Postel’s Principle is a Bad Idea

#52

Post by walshemj »

Arnt wrote: post #44

It's a pity so many people grossly misunderstand Postel's Principle. Postel didn't talk about off-spec behaviour. He talked about the borderline details, which were often quite hazy in early RFCs. When an RFC says the line length is at most 512 bytes and the terminator is CRLF, does that mean 510+CRLF or 512+CRLF? Postel says to accept 512+CRLF and send 510+CRLF. If a write a receiver and want to accept 1024 bytes in…

As some one who used to work on OSI based systems well thats just sloppy standards writing the bane of internet standards.

Its a pity that RFC's and other internet standards are not written and implemented more rigorously - for example Google have problems interpreting the xml sitemap standard and that is only 3 pages FFS.

Re: Postel’s Principle is a Bad Idea

#53

Post by Arnt »

walshemj wrote: post #52
Arnt wrote: post #44

It's a pity so many people grossly misunderstand Postel's Principle. Postel didn't talk about off-spec behaviour. He talked about the borderline details, which were often quite hazy in early RFCs. When an RFC says the line length is at most 512 bytes and the terminator is CRLF, does that mean 510+CRLF or 512+CRLF? Postel says to accept 512+CRLF and send 510+CRLF. If a write a receiver and want to accept 1024 bytes in…

As some one who used to work on OSI based systems well thats just sloppy standards writing the bane of internet standards. Its a pity that RFC's and other internet standards are not written and implemented more rigorously - for example Google have problems interpreting the xml sitemap standard and that is only 3 pages FFS.

I've written ten RFCs of varying quality. It's terribly difficult to write something that a) gives a good overview of the subject, b) explains the choices that had to be made, c) spells out every detail, and d) remains short enough that implementers actually read all of it. All of mine fail in some way. I've heard the OSI documents failed too.

Quoting one implementer, whose code did not accept non-ASCII passwords: "Oh, the password syntax is on page 88? My printout ends after page 68". In that RFC, the details are spelt out in appendices, and Appendix A starts on page 69. (And I'm sure pg assigns bonus karma if you can identify the RFC.)

Re: Postel’s Principle is a Bad Idea

#54

Post by regularfry »

colomon wrote: post #9

It seems to me it is a very valid principle in many areas. For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do…

If the penalty for generating a CAD file with its strings in the wrong encoding is that no importer will read it because they're being strict in what they accept, then no exporter that does so will last very long in the wild.

Re: Postel’s Principle is a Bad Idea

#55

Post by danielweber »

inopinatus wrote: post #6
gruseom wrote: post #3

Earlier quoted context omitted.

when instead they've accidentally built dependencies on other people's implementation details I think it would be very interesting if you could give an example or two of this.

Two off the top of my head: * A classic would be IE's abuse of TCP RST: http://www.stroppykitten.com/cms/index.php?option=com_conten... * A decent chunk of email server code (SMTP & IMAP implementations in particular) is there to handle erroneous client behaviours. The worst cases are those where the workaround leads to misbehaviours (or less optimal behaviours) for conforming clients. If I remember correctly, the po…

POP3 is no picnic, either. Outlook seems to want care about the last-used UIDL.

And, to make things more confusing, the RFC is a little vague about the re-use of UIDLs.

Re: Postel’s Principle is a Bad Idea

#57

Post by derleth »

bartwe wrote: post #48
derleth wrote: post #42

Earlier quoted context omitted.

> http://www.joelonsoftware.com/articles/APIWar.html In the terminology of this article, Torvalds is firmly in the Raymond Chen camp as far as "The kernel is not allowed to break user software" is concerned. The difference between Windows and Linux (and especially between Windows 95 era Windows and Linux of the same vintage) is, apparently, that Linux didn't come from MS-DOS, and so never had to allow application sof…

No this is actually very different. Linus doesn't want breaking API changes to documented behavior, in the Raymond Chen case its not breaking applications that misbehave or abuse undocumented behavior.

> Linus doesn't want breaking API changes to documented behavior

Even aside from the fact this is wrong:

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

http://kerneltrap.org/node/5725

The point I was making was that Linux didn't expose the same kind of deep, undocumented behavior because, as I said, it always had the ability to hide its inner workings.

Re: Postel’s Principle is a Bad Idea

#58

Post by im3w1l »

colomon wrote: post #49
tedunangst wrote: post #29

Earlier quoted context omitted.

The problem is if you decode a particular byte sequence that causes a bad action (if that's possible with step files) in a different way than some other program that is supposed to keep you safe. In the case of ie, ie decoded one way and forum software might decode a different way. So the forum software says the string is safe for the browser (according to its decoding rules) but then the browser applies different ru…

As jbert pointed out, if your program's main job is to say whether or not something is safe, and it liberally says "Oh yeah, I think that's safe", that's pretty much the exact opposite of "be conservative in what you do".

Please explain the proper way of escaping/rejecting html in forum posts, when you can't rely on the browsers following the spec.

Re: Postel’s Principle is a Bad Idea

#59

Post by im3w1l »

Arnt wrote: post #53
walshemj wrote: post #52

Earlier quoted context omitted.

As some one who used to work on OSI based systems well thats just sloppy standards writing the bane of internet standards. Its a pity that RFC's and other internet standards are not written and implemented more rigorously - for example Google have problems interpreting the xml sitemap standard and that is only 3 pages FFS.

I've written ten RFCs of varying quality. It's terribly difficult to write something that a) gives a good overview of the subject, b) explains the choices that had to be made, c) spells out every detail, and d) remains short enough that implementers actually read all of it. All of mine fail in some way. I've heard the OSI documents failed too. Quoting one implementer, whose code did not accept non-ASCII passwords: "O…

Is there any way to request an official clarification for borderline cases the RFC-author didn't think about when typing it up?

Re: Postel’s Principle is a Bad Idea

#60

Post by warmfuzzykitten »

benatkin wrote: post #12

I'd be more interested in reading a paper called How JSON escaped Postel's Principle which included discussion on the ambiguity being pushed to other areas, such as date parsing.

When did that happen? There is a JSON standard, http://www.ietf.org/rfc/rfc4627.txt, but I have yet to find a parser that follows it, including Crockford's original "reference implementation". As a result, there's no point in developing a conformant parser, as no one would use it. They're off chasing date formats, capitalized keywords, functions (!!) blissfully unaware or willfully heedless of the impact on interoperability.
Post reply on HN