3 ms·

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') {

by cft 5y ago

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.

deleted 5y ago
[deleted]
tentacleuno 5y ago
How would this work if the method field was something like "Gibberish"? Would this have any security vulnerabilities?
- deleted 5y ago
  [deleted]
- w-ll 5y ago
  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.
  - jcampbell1 5y ago
    Did you experience any read after write inconsistencies that present as heisenbugs?
    - dotancohen 5y ago
      Would you expect that to be more of an issue under GP's method than with traditional sharding and replication? Presumably writes are then replicated to all instances, just not all instances accept them.
  - Cthulhu_ 5y ago
    "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.
- fulafel 5y ago
  Yep, you can generally get request splitting style vulnerabilities especially as a reverse proxy if you misparse reqs. (And sometimes even if you don't, one reason a rev proxy architecture is somewhat insecure). Hopefully the actual code does a full parse after guessing what to try by the character test heuristic.
Cthulhu_ 5y ago
> 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.

by cft 5y ago

deleted 5y ago

[deleted]

tentacleuno 5y ago

How would this work if the method field was something like "Gibberish"? Would this have any security vulnerabilities?

deleted 5y ago
[deleted]
w-ll 5y ago
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.
- jcampbell1 5y ago
  Did you experience any read after write inconsistencies that present as heisenbugs?
  - dotancohen 5y ago
    Would you expect that to be more of an issue under GP's method than with traditional sharding and replication? Presumably writes are then replicated to all instances, just not all instances accept them.
- Cthulhu_ 5y ago
  "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.
fulafel 5y ago
Yep, you can generally get request splitting style vulnerabilities especially as a reverse proxy if you misparse reqs. (And sometimes even if you don't, one reason a rev proxy architecture is somewhat insecure). Hopefully the actual code does a full parse after guessing what to try by the character test heuristic.

Cthulhu_ 5y ago

> 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.