10 ms·

> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You s

> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway. Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things. > Even if an established protocol (HTTP, SMTP, CSV, FTP) technically requires CRLF as a line ending, do not comply. I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point?

javajosh 2y ago
>What would be the benefit... It is interesting that you ignore the benefits the OP describes and instead present a vague and fearful characterization of the costs. Your reaction lies at the heart of cargo-culting, the maintenance of previous decisions out of sheer dread. One can do a cost-benefit analysis and decide what to do, or you can let your emotions decide. I suggest that the world is better off with the former approach. To wit, the OP notes for benefits " The extra CR serves no useful purpose. It is just a needless complication, a vexation to programmers, and a waste of bandwidth." and a mitigation of the costs "You need to search really, really hard to find a device or application that actually interprets U+000a as a true linefeed." You ignore both the benefits assertion and cost mitigating assertion entirely, which is strong evidence for your emotionality.
- perching_aix 2y ago
  > you ignore the benefits the OP describes Funnily enough, the author doesn't actually describe any tangible benefits. It's all just (in my reading, semi-sarcastic) platonics: - peace - simplicity - the flourishing of humanity ... so instead of "vague and fearful", the author comes on with a "vague and cheerful". Yay? The whole shtick about saving bandwidth, lessening complications, and reducing programmer vexations are only ever implied by the author, and were explicitly considered by the person you were replying to: > You save a handful of bits at the expense of a lot of potential bugs. ... they just happened to be not super convinced. Is this the kind of HackerNews comment I'm supposed to feel impressed by? That demonstrates this forum being so much better than others?
- YZF 2y ago
  What's your estimate for the cost of changing legacy protocols that use CRLF vs. the work that will be done to support those? My intuition (not emotion) agrees with the parent that investing in changing legacy code that works, and doesn't see a lot of churn, is likely a lot more expensive than leaving it be and focusing on new protocols that over time end up replacing the old protocols anyways. OP does not really talk about the benefit, he just opines. How many programmers are vexed when implementing "HTTP, SMTP, CSV, FTP"? I'd argue not many programmers work on implementations of these protocols today. How much traffic is wasted by a few extra characters in these protocols? I'd argue almost nothing. Most of the bits are (binary, compressed) payload anyways. There is no analysis by OP of the cost of not complying with the standard which potentially results in breakage and the difficulty of being able to accurately estimate the breakage/blast radius of that lack of compliance. That just makes software less reliable and less predictable.
- LegionMammal978 2y ago
  The cost is, if people start transitioning to a world where senders only transmit LF in opposition to current standards for protocols like HTTP/1.1 or SMTP (especially aggressively, e.g., by creating popular HTTP libraries without a CRLF option), then it will create the mental and procedural overhead of tracking which receivers accept LF alone vs. which still require CRLF. Switching established protocols is never free, even when there are definite benefits: see the Python 2-to-3 fiasco, caused by newer programs being incompatible with most older libraries.
  - bvrmn 2y ago
    2-to-3 fiasco was solely caused by inadequate support to write py2 compatible code until python 3.4. It was literally "you devs, stop write ugly py2, let's write godly py3".
- michaelmior 2y ago
  You're right that I didn't mention the supposed benefits in my response. But let's incorporate those benefits into new protocols rather than break existing protocols. I just don't see the benefit in intentionally breaking existing protocols.
chasil 2y ago
FYI, Sendmail accepts LF without CR, but Exchange doesn't.
- 9dev 2y ago
  …how very in character for each of them!
- isThereClarity 2y ago
  sendmail 8.18.1 includes patches to correct this behaviour (and options to turn it back on) due to its role in SMTP smuggling, CVE-2023-51765. See https://ftp.sendmail.org/RELEASE_NOTES https://ftp.sendmail.org/RELEASE_NOTES sendmail is now stricter in following the RFCs and rejects some invalid input with respect to line endings and pipelining: ...snip... - Accept only CRLF . CRLF as end of an SMTP message as required by the RFCs, which can disabled by the new srv_features option 'O'. - Do not accept a CR or LF except in the combination CRLF (as required by the RFCs). These checks can be disabled by the new srv_features options 'U' and 'G', respectively. In this case it is suggested to use 'u2' and 'g2' instead so the server replaces offending bare CR or bare LF with a space. It is recommended to only turn these protections off for trusted networks due to the potential for abuse.
phkahler 2y ago
>> I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point? It's not satire and it's not just trying to make a point. It's trying to make things simpler. As he says, a lot of software will accept input without the CR already, even if it's supposed to be there. But we should change the standard over time so people in 2050 can stop writing code that's more complicated (by needing to eat CR) or inserts extra characters. And never mind the 2050 part, just do it today.
- michaelmior 2y ago
  Ignoring established protocols doesn't make things simpler. It makes things vastly more complicated. Let's absolutely fix new protocols (or new versions of existing protocols). But intentionally breaking existing protocols doesn't simplify anything.
- nsnshsuejeb 2y ago
  Yes. We all know how to do this. You know that API version thingy. I agree to drop the carriage return when not needed but do it in future protocols. Obviously IPv6 shows you need to be patient. Your great grandkids may see a useless carriage return! Windows doesn't help here.
  - perching_aix 2y ago
    Versioning provides people with capability for change management, but won't perform it on their behalf. Who knew.
Ekaros 2y ago
Thinking about it. Using CR alone in protocols actually make infinitely more sense. As that would allow use of LF in records. Which would make many use cases much simpler. Just think about text protocols like HTTP, how much easier something like cookies would be to parse if you had CR as terminating character. And then each record separated by LF.
- gpvos 2y ago
  That is so backwards incompatible that it is never, ever going to fly.
- mattmerr 2y ago
  ASCII already has designated bytes for unit, group, and record separators. That aside, a big drawback of using unprintable bytes like these is they're more difficult for humans to read in dumps or type on a keyboard than a newline (provided newline has a strict definition CRLF, LF, etc)
  - fijiaarone 2y ago
    There is no reason those ascii characters need to stay unprintable. You could use other characters like an interpunct, silcrow, or down carat.
    - eqvinox 2y ago
      There is in fact a reason those ASCII 'characters' should stay unprintable: the 0x00-0x1f (except Tab, CR, LF) range is explicitly excluded as invalid in a whole bunch of standards, e.g. XML.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
mechanicalpulse 2y ago
> Why intentionally introduce potential bugs for the sake of making a point? It seems spiteful, but it strikes me as an interesting illustration of how the robustness principle could be hacked to force change. It’s a descriptivist versus prescriptivist view of standards, which is not how we typically view standards.
amluto 2y ago
> I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point? It’s worse than satire. Postel’s Law is definitively wrong, at least in the context of network protocols, and delimiters, especially, MUST be precise. See, for example: https://www.postfix.org/smtp-smuggling.html https://www.postfix.org/smtp-smuggling.html Send exactly what the spec requires, and parse exactly as the spec requires. Do not accept garbage. And LF, where CRLF is specified, is garbage.
- tptacek 2y ago
  If two systems agree, independent of any specification someone somewhere else wrote, to accept a bare NL where a CRLF is specified, that is not "garbage". Standards documents are not laws; the horse drags the cart.
  - DaiPlusPlus 2y ago
    > Standards documents are not laws; the horse drags the cart. They can be: c.f. legally-enforced safety-regulations.
    - tptacek 2y ago
      These aren't.
  - perching_aix 2y ago
    Laws are also just some ink on paper (and are routinely overruled, circumvented or unenforced in certain jurisdictions), so using this kind of logic in order to encourage standard violations is unsound. There is a method to this madness, and that's revising the standards.
    - tptacek 2y ago
      What's a "standard violation"? The original history of the IETF is a rejection of exactly this mode of thinking about the inviolability of standards, which was the ethos of the OSI.
FiloSottile 2y ago
Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and accept CRLF in protocols that specify it, however legacy and nonsensical it might be. (I am a massive, massive SQLite fan, but this is giving me pause about using other software by the same author, at least when networks are involved.)
- deanishe 2y ago
  > but this is giving me pause about using other software by the same author Go read the article again. I think you'll be pleasantly surprised.
- tptacek 2y ago
  This would be more persuasive if HTTP servers didn't already widely accept bare 0ah line termination. What's the first major public web site you can find that doesn't?
  - michaelmior 2y ago
    We're talking about servers and clients here. The best way to ensure things work is to adhere to an established protocol. Aside from saving a few bytes, there doesn't seem to be any good reason to deviate.
    - tptacek 2y ago
      I'm saying the consistency that Filippo says our security depends on doesn't really seem to exist in the world, which hurts the persuasiveness of that particular argument in favor of consistency.
      - dwattttt 2y ago
        But no one expects 0ah to be sufficient. Change that expectation, and now you have to wonder if your middleware and your backend agree on whether the middleware filtered out internal-only headers.
halter73 2y ago
> I'm hoping this is satire. Me too. It's one thing to accept single LFs in protocols that expect CRLF, but sending single LFs is a bridge to far in my opinion. I'm really surprised most of the other replies to your comment currently seem to unironically support not complying with well-established protocol specifications under the misguided notion that it will somehow make things "simpler" or "easier" for developers. I work on Kestrel which is an HTTP server for ASP.NET Core. Kestrel didn't support LF without a CR in HTTP/1.1 request headers until .NET 7 [1]. Thankfully, I'm unaware of any widely used HTTP client that even supports sending HTTP/1.1 requests without CRLF header endings, but we did eventually get reports of custom clients that used only LFs to terminate headers. I admit that we should have recognized a single LF as a line terminator instead of just CRLF from the beginning like the spec suggests, but people using just LF instead of CRLF in their custom clients certainly did not make things any simpler or easier for me as an HTTP server developer. Initially, we wanted to be as strict as possible when parsing request headers to avoid possible HTTP request smuggling attacks. I don't think allowing LF termination really allows for smuggling, but it is something we had to consider. I do not support even adding the option to terminate HTTP/1.1 request/response headers with single LFs in HttpClient/Kestrel. That's just asking for problems because it's so uncommon. There are clients and servers out there that will reject headers with single LFs while they all support CRLF. And if HTTP/1.1 is still being used in 2050 (which seems like a safe bet), I guarantee most clients and servers will still use CRLF header endings. Having multiple ways to represent the exact same thing does not make a protocol simpler or easier. [1]: https://github.com/dotnet/aspnetcore/pull/43202 https://github.com/dotnet/aspnetcore/pull/43202
- jfengel 2y ago
  LF only? Huh. In its original terms for printing terminals, carriage return might be ambiguous. It could means either "just send the print head to column zero" or "print head to 0 and advance the line by one". The latter is what typewriters do for the Return key. But LF always meant Line Feed, moving the paper but not the print head. These are of course wildly out of date concepts. But it still strikes me as odd to see a Line Feed as a context reset.
  - 2y ago
nedt 2y ago
> What would be the benefit Easy - being able to use a plain text protocol as a human being without having to worry if my terminal sends the right end of line terminator. Using netcat to debug SMTP issues is actually something I do often enough.
cassepipe 2y ago
It seems to me the author is not suggesting to update the protocols themselves but rather to stop sending them CR even if the spec requires it. And to patch the corresponding software to it accepts simple newlines.
tfehring 2y ago
At least for CSV, there's a divergence between usage in practice and the spec. The spec requires CRLF, but all of the commonly used tools I've encountered for reading and writing CSVs can read files with CR, LF, or CRLF line endings, and when writing CSVs they'll default to either LF or platform-specific line endings. (Even Excel for Mac doesn't default to CRLF!) I think this divergence is bad and should be fixed. But IMO the right resolution is to update the spec so that (1) readers MUST accept any of (CR, LF, CRLF), (2) writers MUST use one of (CR, LF, CRLF), and (3) writers SHOULD use LF. Removing compatibility from existing applications to break legacy code would be asinine.
- michaelmior 2y ago
  For CSV, "breaking" changes seem like less of a big deal to me. Partially because there is already so much variation in how CSV is implemented.
inopinatus 2y ago
Not just potential bugs, there'll be definite security failures. Changing the line endings can invalidate signatures over plaintext content. So an email MTA, for example, could never do so. Nor most proxy implementations. Then there's the high latent potential for request smuggling, command injection, and privilege escalation, via careful crafting of ambiguous header lines or protocol commands that target less robust implementations. With some protocols, it may cause declared content sizes to be incorrect, leading to bizarre hangs, which is to say, another attack surface. In practice, retiring CRLF can't be safely performed unilaterally or by fiat, we'll need to devise a whole new handshake to affirm that both ends are on the same page re. newline semantics.
jcul 2y ago
Not disagreeing with you, but implementation diverges from spec a lot anyway. I've had to write decoders for things like HTTP, SMTP, SIP (VoIP), and there's so many edge cases and undocumented behavior from different implementations that you have to still support. I find that it affects text based protocols, a lot more than binary protocols. Like TLS, or RTP, to stick with the examples above, have much less divergence and are much less forgiving to broken (according to spec) implementations.
- michaelmior 2y ago
  That's fair, but I don't see that as an argument for intentionally deviating from the spec.

javajosh 2y ago

>What would be the benefit... It is interesting that you ignore the benefits the OP describes and instead present a vague and fearful characterization of the costs. Your reaction lies at the heart of cargo-culting, the maintenance of previous decisions out of sheer dread. One can do a cost-benefit analysis and decide what to do, or you can let your emotions decide. I suggest that the world is better off with the former approach. To wit, the OP notes for benefits " The extra CR serves no useful purpose. It is just a needless complication, a vexation to programmers, and a waste of bandwidth." and a mitigation of the costs "You need to search really, really hard to find a device or application that actually interprets U+000a as a true linefeed." You ignore both the benefits assertion and cost mitigating assertion entirely, which is strong evidence for your emotionality.

perching_aix 2y ago
> you ignore the benefits the OP describes Funnily enough, the author doesn't actually describe any tangible benefits. It's all just (in my reading, semi-sarcastic) platonics: - peace - simplicity - the flourishing of humanity ... so instead of "vague and fearful", the author comes on with a "vague and cheerful". Yay? The whole shtick about saving bandwidth, lessening complications, and reducing programmer vexations are only ever implied by the author, and were explicitly considered by the person you were replying to: > You save a handful of bits at the expense of a lot of potential bugs. ... they just happened to be not super convinced. Is this the kind of HackerNews comment I'm supposed to feel impressed by? That demonstrates this forum being so much better than others?
YZF 2y ago
What's your estimate for the cost of changing legacy protocols that use CRLF vs. the work that will be done to support those? My intuition (not emotion) agrees with the parent that investing in changing legacy code that works, and doesn't see a lot of churn, is likely a lot more expensive than leaving it be and focusing on new protocols that over time end up replacing the old protocols anyways. OP does not really talk about the benefit, he just opines. How many programmers are vexed when implementing "HTTP, SMTP, CSV, FTP"? I'd argue not many programmers work on implementations of these protocols today. How much traffic is wasted by a few extra characters in these protocols? I'd argue almost nothing. Most of the bits are (binary, compressed) payload anyways. There is no analysis by OP of the cost of not complying with the standard which potentially results in breakage and the difficulty of being able to accurately estimate the breakage/blast radius of that lack of compliance. That just makes software less reliable and less predictable.
LegionMammal978 2y ago
The cost is, if people start transitioning to a world where senders only transmit LF in opposition to current standards for protocols like HTTP/1.1 or SMTP (especially aggressively, e.g., by creating popular HTTP libraries without a CRLF option), then it will create the mental and procedural overhead of tracking which receivers accept LF alone vs. which still require CRLF. Switching established protocols is never free, even when there are definite benefits: see the Python 2-to-3 fiasco, caused by newer programs being incompatible with most older libraries.
- bvrmn 2y ago
  2-to-3 fiasco was solely caused by inadequate support to write py2 compatible code until python 3.4. It was literally "you devs, stop write ugly py2, let's write godly py3".
michaelmior 2y ago
You're right that I didn't mention the supposed benefits in my response. But let's incorporate those benefits into new protocols rather than break existing protocols. I just don't see the benefit in intentionally breaking existing protocols.

chasil 2y ago

FYI, Sendmail accepts LF without CR, but Exchange doesn't.

9dev 2y ago
…how very in character for each of them!
isThereClarity 2y ago
sendmail 8.18.1 includes patches to correct this behaviour (and options to turn it back on) due to its role in SMTP smuggling, CVE-2023-51765. See https://ftp.sendmail.org/RELEASE_NOTES https://ftp.sendmail.org/RELEASE_NOTES sendmail is now stricter in following the RFCs and rejects some invalid input with respect to line endings and pipelining: ...snip... - Accept only CRLF . CRLF as end of an SMTP message as required by the RFCs, which can disabled by the new srv_features option 'O'. - Do not accept a CR or LF except in the combination CRLF (as required by the RFCs). These checks can be disabled by the new srv_features options 'U' and 'G', respectively. In this case it is suggested to use 'u2' and 'g2' instead so the server replaces offending bare CR or bare LF with a space. It is recommended to only turn these protections off for trusted networks due to the potential for abuse.

phkahler 2y ago

>> I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point? It's not satire and it's not just trying to make a point. It's trying to make things simpler. As he says, a lot of software will accept input without the CR already, even if it's supposed to be there. But we should change the standard over time so people in 2050 can stop writing code that's more complicated (by needing to eat CR) or inserts extra characters. And never mind the 2050 part, just do it today.

michaelmior 2y ago
Ignoring established protocols doesn't make things simpler. It makes things vastly more complicated. Let's absolutely fix new protocols (or new versions of existing protocols). But intentionally breaking existing protocols doesn't simplify anything.
nsnshsuejeb 2y ago
Yes. We all know how to do this. You know that API version thingy. I agree to drop the carriage return when not needed but do it in future protocols. Obviously IPv6 shows you need to be patient. Your great grandkids may see a useless carriage return! Windows doesn't help here.
- perching_aix 2y ago
  Versioning provides people with capability for change management, but won't perform it on their behalf. Who knew.

Ekaros 2y ago

Thinking about it. Using CR alone in protocols actually make infinitely more sense. As that would allow use of LF in records. Which would make many use cases much simpler. Just think about text protocols like HTTP, how much easier something like cookies would be to parse if you had CR as terminating character. And then each record separated by LF.

gpvos 2y ago
That is so backwards incompatible that it is never, ever going to fly.
mattmerr 2y ago
ASCII already has designated bytes for unit, group, and record separators. That aside, a big drawback of using unprintable bytes like these is they're more difficult for humans to read in dumps or type on a keyboard than a newline (provided newline has a strict definition CRLF, LF, etc)
- fijiaarone 2y ago
  There is no reason those ascii characters need to stay unprintable. You could use other characters like an interpunct, silcrow, or down carat.
  - eqvinox 2y ago
    There is in fact a reason those ASCII 'characters' should stay unprintable: the 0x00-0x1f (except Tab, CR, LF) range is explicitly excluded as invalid in a whole bunch of standards, e.g. XML.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]

mechanicalpulse 2y ago

> Why intentionally introduce potential bugs for the sake of making a point? It seems spiteful, but it strikes me as an interesting illustration of how the robustness principle could be hacked to force change. It’s a descriptivist versus prescriptivist view of standards, which is not how we typically view standards.

amluto 2y ago

> I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point? It’s worse than satire. Postel’s Law is definitively wrong, at least in the context of network protocols, and delimiters, especially, MUST be precise. See, for example: https://www.postfix.org/smtp-smuggling.html https://www.postfix.org/smtp-smuggling.html Send exactly what the spec requires, and parse exactly as the spec requires. Do not accept garbage. And LF, where CRLF is specified, is garbage.

tptacek 2y ago
If two systems agree, independent of any specification someone somewhere else wrote, to accept a bare NL where a CRLF is specified, that is not "garbage". Standards documents are not laws; the horse drags the cart.
- DaiPlusPlus 2y ago
  > Standards documents are not laws; the horse drags the cart. They can be: c.f. legally-enforced safety-regulations.
  - tptacek 2y ago
    These aren't.
- perching_aix 2y ago
  Laws are also just some ink on paper (and are routinely overruled, circumvented or unenforced in certain jurisdictions), so using this kind of logic in order to encourage standard violations is unsound. There is a method to this madness, and that's revising the standards.
  - tptacek 2y ago
    What's a "standard violation"? The original history of the IETF is a rejection of exactly this mode of thinking about the inviolability of standards, which was the ethos of the OSI.

FiloSottile 2y ago

Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and accept CRLF in protocols that specify it, however legacy and nonsensical it might be. (I am a massive, massive SQLite fan, but this is giving me pause about using other software by the same author, at least when networks are involved.)

deanishe 2y ago
> but this is giving me pause about using other software by the same author Go read the article again. I think you'll be pleasantly surprised.
tptacek 2y ago
This would be more persuasive if HTTP servers didn't already widely accept bare 0ah line termination. What's the first major public web site you can find that doesn't?
- michaelmior 2y ago
  We're talking about servers and clients here. The best way to ensure things work is to adhere to an established protocol. Aside from saving a few bytes, there doesn't seem to be any good reason to deviate.
  - tptacek 2y ago
    I'm saying the consistency that Filippo says our security depends on doesn't really seem to exist in the world, which hurts the persuasiveness of that particular argument in favor of consistency.
    - dwattttt 2y ago
      But no one expects 0ah to be sufficient. Change that expectation, and now you have to wonder if your middleware and your backend agree on whether the middleware filtered out internal-only headers.

halter73 2y ago

> I'm hoping this is satire. Me too. It's one thing to accept single LFs in protocols that expect CRLF, but sending single LFs is a bridge to far in my opinion. I'm really surprised most of the other replies to your comment currently seem to unironically support not complying with well-established protocol specifications under the misguided notion that it will somehow make things "simpler" or "easier" for developers. I work on Kestrel which is an HTTP server for ASP.NET Core. Kestrel didn't support LF without a CR in HTTP/1.1 request headers until .NET 7 [1]. Thankfully, I'm unaware of any widely used HTTP client that even supports sending HTTP/1.1 requests without CRLF header endings, but we did eventually get reports of custom clients that used only LFs to terminate headers. I admit that we should have recognized a single LF as a line terminator instead of just CRLF from the beginning like the spec suggests, but people using just LF instead of CRLF in their custom clients certainly did not make things any simpler or easier for me as an HTTP server developer. Initially, we wanted to be as strict as possible when parsing request headers to avoid possible HTTP request smuggling attacks. I don't think allowing LF termination really allows for smuggling, but it is something we had to consider. I do not support even adding the option to terminate HTTP/1.1 request/response headers with single LFs in HttpClient/Kestrel. That's just asking for problems because it's so uncommon. There are clients and servers out there that will reject headers with single LFs while they all support CRLF. And if HTTP/1.1 is still being used in 2050 (which seems like a safe bet), I guarantee most clients and servers will still use CRLF header endings. Having multiple ways to represent the exact same thing does not make a protocol simpler or easier. [1]: https://github.com/dotnet/aspnetcore/pull/43202 https://github.com/dotnet/aspnetcore/pull/43202

jfengel 2y ago
LF only? Huh. In its original terms for printing terminals, carriage return might be ambiguous. It could means either "just send the print head to column zero" or "print head to 0 and advance the line by one". The latter is what typewriters do for the Return key. But LF always meant Line Feed, moving the paper but not the print head. These are of course wildly out of date concepts. But it still strikes me as odd to see a Line Feed as a context reset.
- 2y ago

nedt 2y ago

> What would be the benefit Easy - being able to use a plain text protocol as a human being without having to worry if my terminal sends the right end of line terminator. Using netcat to debug SMTP issues is actually something I do often enough.

cassepipe 2y ago

It seems to me the author is not suggesting to update the protocols themselves but rather to stop sending them CR even if the spec requires it. And to patch the corresponding software to it accepts simple newlines.

tfehring 2y ago

At least for CSV, there's a divergence between usage in practice and the spec. The spec requires CRLF, but all of the commonly used tools I've encountered for reading and writing CSVs can read files with CR, LF, or CRLF line endings, and when writing CSVs they'll default to either LF or platform-specific line endings. (Even Excel for Mac doesn't default to CRLF!) I think this divergence is bad and should be fixed. But IMO the right resolution is to update the spec so that (1) readers MUST accept any of (CR, LF, CRLF), (2) writers MUST use one of (CR, LF, CRLF), and (3) writers SHOULD use LF. Removing compatibility from existing applications to break legacy code would be asinine.

michaelmior 2y ago
For CSV, "breaking" changes seem like less of a big deal to me. Partially because there is already so much variation in how CSV is implemented.

inopinatus 2y ago

Not just potential bugs, there'll be definite security failures. Changing the line endings can invalidate signatures over plaintext content. So an email MTA, for example, could never do so. Nor most proxy implementations. Then there's the high latent potential for request smuggling, command injection, and privilege escalation, via careful crafting of ambiguous header lines or protocol commands that target less robust implementations. With some protocols, it may cause declared content sizes to be incorrect, leading to bizarre hangs, which is to say, another attack surface. In practice, retiring CRLF can't be safely performed unilaterally or by fiat, we'll need to devise a whole new handshake to affirm that both ends are on the same page re. newline semantics.

jcul 2y ago

Not disagreeing with you, but implementation diverges from spec a lot anyway. I've had to write decoders for things like HTTP, SMTP, SIP (VoIP), and there's so many edge cases and undocumented behavior from different implementations that you have to still support. I find that it affects text based protocols, a lot more than binary protocols. Like TLS, or RTP, to stick with the examples above, have much less divergence and are much less forgiving to broken (according to spec) implementations.

michaelmior 2y ago
That's fair, but I don't see that as an argument for intentionally deviating from the spec.