sozu icon indicating copy to clipboard operation
sozu copied to clipboard

buffering changes to allow header rules

Open Geal opened this issue 5 years ago • 2 comments

right now, sozu is built to handle very large requests: it only cares about the path and the Host header for routing (and, in some cases, the sticky session cookie). Once it has seen them, it starts forwarding data to the backend. While this has been useful to handle some weird request (like very large cookies), it is limiting what we can do in routing. I'd like to add rules depending on the presence or content of some headers. There are only 2 ways to do that:

  • allocate buffers to store the header content
  • put a hard limit on the request size: the request line or status line and all the headers should be smaller than the buffer size (the content can be streamed once we have parsed the request and done the routing)

This would make routing slightly slower in some cases (when we get the routing info but not all headers have come, which is rare), but would make parsing and routing easier, and allow more features

Geal avatar Jun 20 '19 16:06 Geal

Plan:

  • [x] in lib/src/protocol/http/mod.rs, wait for all the headers to be parsed to start proxying
  • [ ] define a structure to represent a type of header and its position
    • issue: currently, buffering is defined around the BufferQueue struct that indicates parsing and streaming state: position of currently valid data, end of currently parsed data, position at which we start parsing again (in case of chunking, etc). Headers could point to data that is marked as parsed and ready to be shipped to the backend
  • [ ] is the current buffer structure still adapted?
    • we could use bytes::Bytes, which would make it easier to pass data around
    • do we adapt the BufferQueue to do a bit more?
      • the parser could generate a list of structures referring to the buffer, ie request line from here to there, Host header from here to there, etc. We could then apply filters to this list (which would make headers rewriting a bit easier)
  • [ ] define how header rules work. Can they be stacked, do we use them for routing? Do we use a list of filters instead of testing rules one by one?

Geal avatar Jun 21 '19 13:06 Geal

note: those header changes are necessary for: -HTTP/2 support ( https://github.com/sozu-proxy/sozu/issues/540 ) to separate the client and server HTTP 1 implementations and transmit data between HTTP1 and HTTP/2 parts

  • io_uring: with a clearer separation of the buffers, we will be able to lend them to the kernel to execute tasks list with io_uring
  • wasm plugins #685: we should give access to the headers to wasm plugins, without having them parse again the headers

Geal avatar Jul 29 '21 09:07 Geal