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

The curious case of the missing period

tjaart.substack.com

Post reply on HN
Print view View original

191–200 of 201 posts

Re: The curious case of the missing period

#191

Post by treflop »

TeMPOraL wrote: post #190
treflop wrote: post #188

Earlier quoted context omitted.

Injecting random data into any protocol will break it. When we’re talking about whether someone can inject data into the link, we’re talking about the end user and not the software. If we’re talking protocol design, then you wouldn’t want regular data to be able to inject commands by simply existing.

> Injecting random data into any protocol will break it. It shouldn't, unless you're bypassing the actual protocol serialization layer (or hitting a bug in the implementation). Which is what's the case here. Protocol design can't address the case of users just writing out some bytes and declaring it's a valid protocol message.

Sure but I’m not replying to the thread.

I’m replying to a post where someone said most protocols have in-band signaling and therefore this problem is unavoidable.

Re: The curious case of the missing period

#192

Post by spankalee »

TeMPOraL wrote: post #185
spankalee wrote: post #154

Earlier quoted context omitted.

> [1] - Templating systems themselves are thus a mistake belonging to this class This is not universally true. JavaScript has an amazing feature called tagged template literals which let you tag a string with interpolations with a function that handles the literal and interpolation parts separately. This lets the tag function handle the literals as trusted developer written HTML or SQL, and the interpolations as untr…

That's exactly the kind of hack that worries me. Your example is still (seemingly[0]) gluing text at serialized level, ignoring the actual structure of HTML language. ${name} should never be able to insert any text that would end up being interpreted as markup. Not only when some code decides it's not user-provided; it's not even possible to make that test be 100% accurate, and it doesn't protect you from mistakes in…

Your assumptions here are very, very wrong. Calling it a hack is only telling on yourself, honestly.

Lit is not working at the serialized level, at all. It parses the templates independently of any values, and the values are inserted into the already parsed tree structure. There's is literally no way for values to be parsed as HTML.

Re: The curious case of the missing period

#193

Post by boxed »

doktrin wrote: post #156
angst_ridden wrote: post #151

Earlier quoted context omitted.

"I cannot recommend X too highly. X always served as an example to their colleagues. The quality of X's code was unequalled in our department, and X's work always merited special attention." (etc)

> I cannot recommend X too highly This isn't a veiled statement. It's outright dunking on the applicant.

My take away from this is that any positive thing written in a letter of recommendation can be read as sarcasm by an English speaker.

I think there's some deeper issue with the language/culture here.

Re: The curious case of the missing period

#194

Post by Animats »

throw10920 wrote: post #187
Animats wrote: post #178

Earlier quoted context omitted.

SMTP is that way because running the entire contents of a message through some escape character processing was expensive back then, in the era of 0.25 MIPS machines.

Thank you for weighing in, John Nagle! I understand that constraint, and it seems reasonable - but in that case, why not use a length prefix? That should be even more efficient than having to scan for a line containing a single period and nothing else.

Because many paths of that era were not binary-transparent. There was CR-LF to LF conversion, the possibility of ASCII/EBCDIC translation, and other transformations.

Hence such horrors as MIME delimiters:

    -----=_Part_2827761_1947716067.1716352583971
    Content-Type: multipart/alternative; 
    boundary="----=_Part_2827760_1372041171.1716352583736"
We still have the mess that is the required and standardized behavior of HTML5 parsers faced with bad data.

Re: The curious case of the missing period

#195

Post by doktrin »

thedanbob wrote: post #159
doktrin wrote: post #156

Earlier quoted context omitted.

> I cannot recommend X too highly This isn't a veiled statement. It's outright dunking on the applicant.

It can be interpreted both ways: "I cannot recommend X too highly (because they suck)" vs "I cannot recommend X too highly (because whatever praise I give will be inadequate)"

If praise is the intent, it would be phrased as "... cannot recommend X highly enough"

Re: The curious case of the missing period

#196

Post by doktrin »

boxed wrote: post #193
doktrin wrote: post #156

Earlier quoted context omitted.

> I cannot recommend X too highly This isn't a veiled statement. It's outright dunking on the applicant.

My take away from this is that any positive thing written in a letter of recommendation can be read as sarcasm by an English speaker. I think there's some deeper issue with the language/culture here.

Every language has turns of phrase that are not necessarily intuitive to non-native speakers.

Re: The curious case of the missing period

#197

Post by otterley »

teddyh wrote: post #164
otterley wrote: post #25

Earlier quoted context omitted.

> Don’t vendor your dependencies. The alternative seems worse: your own application's stability is now at risk against upstream changes that could break your code. Sure, you might not get a fix immediately, but I'd rather know I'm making a change because I need a fix than introducing instability and additional risk that I don't want to subject myself to. "If it ain't broke, don't fix it."

You can choose to either live at the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, as discussed here: https://news.ycombinator.com/item?id=21785399 > (And surely you should have tests to verify all your own functionality after upgrading a dependency?)

That "should" is load bearing. Unfortunately thorough automated testing isn't frequently done by application teams, and even fewer automated testing of dependencies is done by them. Most developers assume, for better or worse, that testing of dependencies is the responsibility of their respective authors.

Re: The curious case of the missing period

#198

Post by MiguelX413 »

doktrin wrote: post #195
thedanbob wrote: post #159

Earlier quoted context omitted.

It can be interpreted both ways: "I cannot recommend X too highly (because they suck)" vs "I cannot recommend X too highly (because whatever praise I give will be inadequate)"

If praise is the intent, it would be phrased as "... cannot recommend X highly enough "

I disagree.

Re: The curious case of the missing period

#200

Post by aftoprokrustes »

Biganon wrote: post #75
aftoprokrustes wrote: post #60

I will not comment on the technical part, as others already did it better than I could, but it just reminded me of an anecdote that reminds of the importance of such trivial things as a period at the end of a sentence: In Germany, where I work, it is usual at the end of employement to ask for a letter of recommendation ("Zeugnis") that lists the tasks performed, and how good the employee was. It is an important docum…

Secret codes being used in recommandation letters are an urban legend. HR people have no incentive to create a secret code for them and their potential rivals, let alone teach it to new HR people while also keeping it secret. This legend comes from the fact that HR people cannot be too explicit about the fact that you've been a pain in the ass (you could probably sue if it's too transparent), so if they have nothing…

As other commenters said, what you describe could actually be considered a secret code.

But in the specific german case, the code is not even that secret. This is a formal document with a very specific structure, and very standardized phrases. There is even specific software to generate the text out of performance ratings. Basically something like this:

- John was overal engaged: he is a lazy bastard

- John was engaged: he is OK

- john was very engaged: he is good

- john was always very and thoroughly engaged: he is very good

Post reply on HN