Reimplement buffer rewriting for headers

[Geal]

In gitlab by @Geal on Apr 11, 2016, 19:11

Right now, the additional headers are inserted right into the input buffer, and if it is nearly full, we might not be able to insert them.

A better solution (the one implemented in HAProxy, I think) would be to avoid editing the buffer, and instead remember which slices of the input buffer to send (if some data was deleted), and which external slices (header rewriting, additional header) should be inserted.

Then, in the writable and back_writable, instead of passing just one buffer, the proxy would go through a list of slices to write to the socket. Some would advance the input buffer position, some would not.

This solution requires the parser to send back a list of subslices, and the proxy to track the end of headers (to insert headers at the right position).

[Geal]

In gitlab by @Geal on Apr 11, 2016, 19:26

This could be represented by a vector of this enum:

enum StuffToWrite {
  BufferSlice(start, end), // we can handle absolute positions, from the start of client data stream
  Data(Vec<u8>), // an owned vector containing things like additional headers
  Splice(usize), // indicates how much data should be copied through splicing
}

This way, we could encode useful scenarii like this one:

• buffer contains 1000 bytes of data
• don't pass the slice from 50 to 75 to the backend
• insert the string "Request-id: 1234"
• copy the rest of the buffer
• splice 30000 bytes of data afterwards

This would be encoded, with end of headers at 120, as [BufferSlice(0, 50), BufferSlice(75, 120), Data("Request-id: 1234"), BufferSlice(120, 1000), Splice(30000)]

The difficulty will probably lie in calculating positions and offsets, since because of deletions and inserts, there will be differences between input buffer position, and resulting stream position.

[Geal]

In gitlab by @Geal on Oct 3, 2016, 17:04

Done