Hacker News new | ask | show | jobs
by founderling 2374 days ago

    opaque byte arrays, only available operation is
    rendering into a bounded area
Goodbye web then. Because the whole request you get from a client is nothing but strings.

So when you run an onlineshop and a customer orders "7" screwdrivers - then you are screwed. Because what does an "opaque byte array" of "opaque byte arrays" cost? How much shipping will that be?

But at least you have a brand new customer: Henry@gmail.com. Since you do not lowercase the email and do not recognize him as henry@gmail.com which he used in his last order.

3 comments

>But at least you have a brand new customer: Henry@gmail.com. Since you do not lowercase the email and do not recognise him as henry@gmail.com which he used in his last order

You may not like it but this is fully standards-compliant behaviour. RFC 5321 states:

>The local-part of a mailbox MUST BE treated as case sensitive

I'm not saying this is a good behaviour and the RFC also discourages exploiting it further.

There are more ways an email address can be equivalent though :-). Since we know it's gmail in this case we know the email address is both case insensitive and dots don't matter. Comments are also allowed in email addresses (in both the local part and the domain part). Here's a couple examples from RFC 2822:

  pete(his account)@silly.test(his host)
  c@(Chris's host.)public.example
[0] https://tools.ietf.org/html/rfc5321

[1] https://support.google.com/mail/answer/7436150

[2] https://www.ietf.org/rfc/rfc2822.html#appendix-A.5

> But at least you have a brand new customer: Henry@gmail.com. Since you do not lowercase the email and do not recognize him as henry@gmail.com which he used in his last order.

Which would be correct behaviour. From RFC 5321, part 2.4, "The local-part of a mailbox MUST BE treated as case sensitive."

That's a good point, these problems are not easy to solve. But they should be solved.

For example, the user types "7" into the UI control. The UI control knows it's supposed to hold a number, so it has methods that return the parsed number (done by the OS, very carefully), or an error to the user.

Similarly, you don't send the product name, but the ID of the product the user selected from their fuzzy search. I would go as far as using this technique for the email too.