am i a bad person that by the mentioning of "Igor" I'm immediately reminded of Young Frankenstein?
Do svidaniya, Igor, and thank you for Nginx
301–310 of 366 posts
Re: Do svidaniya, Igor, and thank you for Nginx
#302Earlier quoted context omitted.
Do (до) is basically “till” Svidaniye (Свидание) has several meanings: - most common modern single-word usage is for date as in “romantic date” - archaic is for “meeting” that remained in this goodbye form. So “do svidaniya” is literally for “till we meet again” :-)
I wonder why is it romanized to "do", when it's read as "da"?
English. The answer is almost always English, and its "quirky" way of transliteration.
Re: Do svidaniya, Igor, and thank you for Nginx
#303Earlier quoted context omitted.
I wonder why is it romanized to "do", when it's read as "da"?
English. The answer is almost always English, and its "quirky" way of transliteration.
I don't think so. From what little Russian I know, the original is до свидания, with an O, but in most dialects an unstressed O is pronounced A: https://en.wikipedia.org/wiki/Russian_phonology#Unstressed_v...
Re: Do svidaniya, Igor, and thank you for Nginx
#304Earlier quoted context omitted.
Do (до) is basically “till” Svidaniye (Свидание) has several meanings: - most common modern single-word usage is for date as in “romantic date” - archaic is for “meeting” that remained in this goodbye form. So “do svidaniya” is literally for “till we meet again” :-)
I wonder why is it romanized to "do", when it's read as "da"?
Because it's spelt "do" in Russian. It's only due to stress and the fact it's a preposition that the way it is said becomes "da".
As the preposition is so small, it's considered together with the following word, which in the genitive has its stress on the "а".
Re: Do svidaniya, Igor, and thank you for Nginx
#305Earlier quoted context omitted.
Doing Boyer and Moore proud. I think that if you want to support all verbs, you face at least 3 'ambiguities' whether you first check the first, second, or third character of the string. (It must be at most the third, as the shortest verbs are 3 characters long.) First checking the first character is ambiguous between POST , PUT and PATCH . First checking the second character is ambiguous between HEAD , DELETE , and…
Most requests in reality are GET. So if you first check for G, if (m[0] == 'G') { r->method = NGX_HTTP_GET; break; } else if (m[0] == 'P') { switch(m[1]) { ... } } else if ... this should be fast enough.
> this should be fast enough.
'Should' implies uncertainty; 'fast enough' implies there's no speed constraints / requirements. This particular bit of code - checking what request type is coming in - will be executed trillions of times across millions of servers across decades; it's the kind of thing you want to be as fast and secure as possible, so it's worth taking away these insecurities and guesses about performance.
Re: Do svidaniya, Igor, and thank you for Nginx
#306Earlier quoted context omitted.
How would this work if the method field was something like "Gibberish"? Would this have any security vulnerabilities?
If its "Gibberish" I'd suggest it's safer to assume it as a Get request regardless. Something I don't see many people talk about, but I've setup web instances with both read and write clusters similar to db's, and have the nicety to getting more umph from the read cluster by making sure it only hits read db nodes and disabling any framework stuff for tracking changes on a model.
"Safer to assume" is making a lot of assumptions already. What if nginx itself or some other application behind it makes assumptions about the maximum length of a request method, and it causes a buffer overflow?
I expect anything that talks HTTP to reject requests with invalid HTTP methods. HTTP is a well-known standard and servers do not need to accomodate for sloppy, wrong, or malicious implementations.
Re: Do svidaniya, Igor, and thank you for Nginx
#307Earlier quoted context omitted.
That's why we rely on people like you to update article at wikipedia, your services are invaluable!
When I do this, with sources, I find some power user has reverted the change within minutes or hours without so much as a meaningful comment. Not sure when it happened, but Wikipedia has long been a collection of fiefdoms, jealously guarded by power users and their sycophants.
If only said power users used their time and energy to fix content instead of just revert it.
Re: Do svidaniya, Igor, and thank you for Nginx
#308Earlier quoted context omitted.
i speak russian fluently and still parsed the title as "Do" +
I'm not fluent, but I've been studying for 3 years now. I hate when people use latin characters to 'sound out' russian words. When I see Cyrillic, my brain immediately switches to Russian. When it's latin sounding out Russian, it takes a stupid amount of time for me to realize and comprehend what they are trying to say.
> I hate when people use latin characters to 'sound out' russian words
Except nobody knows how the Russian characters even sounds:
Re: Do svidaniya, Igor, and thank you for Nginx
#309Earlier quoted context omitted.
A bit of a micro-optimization, but couldn’t you interpret 4 bytes (including the trailing null on the three-letter verbs) as a 32-bit unsigned int and then do integer comparisons or a case statement?
NGINX does exactly that (after finding the space character after the verb): https://github.com/nginx/nginx/blob/7587778a33bea0ce6f203a8c... There are several points to note: This trick only works if the architecture supports unaligned memory access. Macros are used instead of functions, so you don't have to rely on the compiler to do inlining. The shifts and ors should get optimized out by the compiler. I once tried…
Ah nice! I was interested in looking but don’t know the codebase.
That method does look better. My idea assumes that the method has already been checked to see if it is a valid method, which has its own cost. Otherwise, POSABC would be parsed as POST. Their method does that more or less on the fly.
Re: Do svidaniya, Igor, and thank you for Nginx
#310I can't help having bad feelings about this. The first thing I could think of was what Google has become during the post-Brin-Page era. I hope I'm wrong but this could be an indicator of some changes F5 is about to introduce.
I mean, as soon as F5 bought nginx you could have predicted that.