6 ms·

As a web developer who isn't familiar with assembly or any web server more barebones than nginx, what benefits does something like this provide? Speed? Could th

As a web developer who isn't familiar with assembly or any web server more barebones than nginx, what benefits does something like this provide? Speed? Could this be a solution for an extremely simple directory/static file web server?

hcarvalhoalves 13y ago
This is obviously a toy, or PoC.
- ars_technician 13y ago
  I don't know about calling it a piece of crap. Seems a little harsh. :-)
  - jamestanderson 13y ago
    It could mean proof of concept.
    - wanda 13y ago
      I think that smile could mean that he's being facetious.
    - solistice 13y ago
      Incidentally, I read it the other way as well.
  - deleted 13y ago
    [deleted]
  - deleted 13y ago
    [deleted]
  - optymizer 13y ago
    I don't normally see 'piece of crap' written as PoC. I'm used to seeing PoS used often. I usually see PoC as 'proof of concept'.
  - UNIXgod 13y ago
    Definitely meant it's ROFL web scale, asynchronous, non-blocking, event driven, message passing, nosql, sharded, clusters of highly available, reliable, high performance, real time, bad ass, rockstar, get the girls, get the funding, get the IPO, impress your mom, impress your cat ... applications.
  - tinco 13y ago
    Haha, imagine what tech news would be like if every time you saw PoC you thought it meant piece of crap. Quite hilarious actually.
anonymouscowar1 13y ago
This is a simple, single-threaded single-process accept-read-respond-loop web server. It's vulnerable to trivial trickle DoS attacks and probably has other issues. There are no advantages, the author just did this for fun. The TCP part comes from C code in the kernel, so this headline is a little misleading ;-).
- kragen 13y ago
  Agreed. However, it should be safe from buffer overflows, path traversal attacks, XSS, and obviously CSRF. It should be fine other than DoS. Let me know if you find any exceptions.
  - anonymouscowar1 13y ago
    It's hard to be vulnerable to XSS and CSRF with all-static content, no? So, not only will a trickle DoS other clients, each byte will also force an O(n) traversal of $buf (burning CPU). Granted, buf is only 1000 bytes, but that's not great. It looks like a request with no space could force you to walk (`repne scasb`) through invalid memory after $buf. Also maybe corrupt it (unescape_request_path). It will also fail to correctly parse HTTP/0.9 (not a big deal, but part of spec). The parsing code ignores the existence of verbs other than GET. (Doesn't check that the verb is GET either.) We don't validate that paths start with /, we just skip that byte. Okay: mov (path), %al ... cmp $'/, %al je badreq Since valid GETs are of the form: GET /foo.txt HTTP/1.0 ^-- path=buf+5 As you point out, a client close will cause SIGPIPE causing a crash (DoS). That's all I see. But I'm not an asm expert and I'm sure I've missed something.
    - kragen 13y ago
      > It's hard to be vulnerable to XSS and CSRF with all-static content, no? You would think, but actually Apache managed to be vulnerable to XSS by including bits of the request URL in its error paegs, if I remember right. Last millennium, I think. > So, not only will a trickle DoS other clients, each byte will also force an O(n) traversal of $buf (burning CPU). Granted, buf is only 1000 bytes, but that's not great. Hmm, while I hadn't thought about that, and I should have, I think that's probably okay; basically you're saying that you can get the machine to burn up to, say, 2048 cycles by sending it a small TCP packet. Which means that a 4-core 2GHz server machine can't handle more than about four million packets per second (well, one million until I parallelize), which is about 85 megabytes per second, or 680 megabits per second. There are probably other bottlenecks in the code, the kernel, or your data center that will kick in first. It's probably more effective to DoS the server by just requesting files from it. > It looks like a request with no space could force you to walk (`repne scasb`) through invalid memory after $buf. It's possible I could have gotten this wrong, but I did try to limit the number of bytes it would scan to the bytes that it had actually read, by doing mov (bufp), %ecx before the repne scasb. Did I screw that up? > HTTP/0.9 ...verbs other than GET. Yes, those are unimplemented features, and you're right that their lack makes the server behave incorrectly; hopefully they don't result in security bugs. I think they don't matter in practice, since nobody sends HTTP/0.9 requests or HEAD requests, except by hand, do they? > We don't validate that paths start with /, we just skip that byte. Right. And the $'/ check below is to keep you from saying GET //etc/passwd HTTP/1.0 and getting /etc/passwd. In case that matters in 2013. Thank you very much for looking over it!
knappador 13y ago
This is normally the kind of question I ask about anything involving HTML/CSS only or JS only =D PoC's based on low-level concepts are the ones that make you curious about everything from top to bottom. Even though assembly is the least abstract and most esoteric of programming (some would argue opposite) spaces, the program actually reveals itself quite quickly knowing just a few tid-bits. This is how you get to see that even the most low-level aspects of programming are quite accessible.
- kragen 13y ago
  Thank you! I'm glad to hear that you found it so readable.
kragen 13y ago
Nginx will almost certainly be faster, and is somewhat robust against DoS attacks. I didn't write this to provide benefits. There are situations where this would work better than nginx (where, say, you don't want to spend any time configuring anything) but there are better existing solutions for those cases.

hcarvalhoalves 13y ago

This is obviously a toy, or PoC.

ars_technician 13y ago
I don't know about calling it a piece of crap. Seems a little harsh. :-)
- jamestanderson 13y ago
  It could mean proof of concept.
  - wanda 13y ago
    I think that smile could mean that he's being facetious.
  - solistice 13y ago
    Incidentally, I read it the other way as well.
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
- optymizer 13y ago
  I don't normally see 'piece of crap' written as PoC. I'm used to seeing PoS used often. I usually see PoC as 'proof of concept'.
- UNIXgod 13y ago
  Definitely meant it's ROFL web scale, asynchronous, non-blocking, event driven, message passing, nosql, sharded, clusters of highly available, reliable, high performance, real time, bad ass, rockstar, get the girls, get the funding, get the IPO, impress your mom, impress your cat ... applications.
- tinco 13y ago
  Haha, imagine what tech news would be like if every time you saw PoC you thought it meant piece of crap. Quite hilarious actually.

anonymouscowar1 13y ago

This is a simple, single-threaded single-process accept-read-respond-loop web server. It's vulnerable to trivial trickle DoS attacks and probably has other issues. There are no advantages, the author just did this for fun. The TCP part comes from C code in the kernel, so this headline is a little misleading ;-).

kragen 13y ago
Agreed. However, it should be safe from buffer overflows, path traversal attacks, XSS, and obviously CSRF. It should be fine other than DoS. Let me know if you find any exceptions.
- anonymouscowar1 13y ago
  It's hard to be vulnerable to XSS and CSRF with all-static content, no? So, not only will a trickle DoS other clients, each byte will also force an O(n) traversal of $buf (burning CPU). Granted, buf is only 1000 bytes, but that's not great. It looks like a request with no space could force you to walk (`repne scasb`) through invalid memory after $buf. Also maybe corrupt it (unescape_request_path). It will also fail to correctly parse HTTP/0.9 (not a big deal, but part of spec). The parsing code ignores the existence of verbs other than GET. (Doesn't check that the verb is GET either.) We don't validate that paths start with /, we just skip that byte. Okay: mov (path), %al ... cmp $'/, %al je badreq Since valid GETs are of the form: GET /foo.txt HTTP/1.0 ^-- path=buf+5 As you point out, a client close will cause SIGPIPE causing a crash (DoS). That's all I see. But I'm not an asm expert and I'm sure I've missed something.
  - kragen 13y ago
    > It's hard to be vulnerable to XSS and CSRF with all-static content, no? You would think, but actually Apache managed to be vulnerable to XSS by including bits of the request URL in its error paegs, if I remember right. Last millennium, I think. > So, not only will a trickle DoS other clients, each byte will also force an O(n) traversal of $buf (burning CPU). Granted, buf is only 1000 bytes, but that's not great. Hmm, while I hadn't thought about that, and I should have, I think that's probably okay; basically you're saying that you can get the machine to burn up to, say, 2048 cycles by sending it a small TCP packet. Which means that a 4-core 2GHz server machine can't handle more than about four million packets per second (well, one million until I parallelize), which is about 85 megabytes per second, or 680 megabits per second. There are probably other bottlenecks in the code, the kernel, or your data center that will kick in first. It's probably more effective to DoS the server by just requesting files from it. > It looks like a request with no space could force you to walk (`repne scasb`) through invalid memory after $buf. It's possible I could have gotten this wrong, but I did try to limit the number of bytes it would scan to the bytes that it had actually read, by doing mov (bufp), %ecx before the repne scasb. Did I screw that up? > HTTP/0.9 ...verbs other than GET. Yes, those are unimplemented features, and you're right that their lack makes the server behave incorrectly; hopefully they don't result in security bugs. I think they don't matter in practice, since nobody sends HTTP/0.9 requests or HEAD requests, except by hand, do they? > We don't validate that paths start with /, we just skip that byte. Right. And the $'/ check below is to keep you from saying GET //etc/passwd HTTP/1.0 and getting /etc/passwd. In case that matters in 2013. Thank you very much for looking over it!

knappador 13y ago

This is normally the kind of question I ask about anything involving HTML/CSS only or JS only =D PoC's based on low-level concepts are the ones that make you curious about everything from top to bottom. Even though assembly is the least abstract and most esoteric of programming (some would argue opposite) spaces, the program actually reveals itself quite quickly knowing just a few tid-bits. This is how you get to see that even the most low-level aspects of programming are quite accessible.

kragen 13y ago
Thank you! I'm glad to hear that you found it so readable.

kragen 13y ago

Nginx will almost certainly be faster, and is somewhat robust against DoS attacks. I didn't write this to provide benefits. There are situations where this would work better than nginx (where, say, you don't want to spend any time configuring anything) but there are better existing solutions for those cases.