Delayed content processing

[btiplitz]

Is your feature request related to a problem? Please describe.
When the content request comes in and the processing will be delayed, duplicating the memory creates memory pressure. I would like to be able to swap the content string into my own string so I don't have to make a copy, but I plan to return the response to the sender before completion (which in my case is a re-direct)

Describe why the feature or enhancement you are proposing fits the library.
The content is not necessary to be used by the library once I have received it

Describe the solution you'd like
Either I'd like to be able to get a non-constant pointer to the content, or a way to pass my std::string for the swap within the lirbary

Describe alternatives you've considered
I make a copy now. I've considered just modifying the code I have myself and still might. I could easily submit a PR for this but have not contributed to this project before

Additional context
Add any other context or screenshots about the feature request here.

[etr]

Hey @btiplitz, thanks for the request. Can you attach a piece of code showing what you are trying to do? I am not sure why you are having to make a copy of the value unless you are modifying it before returning it. I am also not sure of what you mean by "I plan to return the response to the sender before completion" so I think an example might help to understand your use-case.

The main reason the content string is currently immutable is to keep the immutability of the overall http_request object which has its advantages both in internal management of the library and to avoid unintended behaviors. Said that, I am not necessarily locked onto anything.

[btiplitz]

I'll get you a snipped later this week. The reason I have to make a copy of the data as it could take minutes to process the data. The only response that is sent back is the data has been accepted for processing, thus I need to make a copy of the data

The logic is

1. Receive data. Send back redirect
2. Receive delete. Send back ok once the data has been staged for processing, which includes journal operations.
3. Process data, but the sender is no longer involved, so there are no more http requests on this transaction

I understand the need to keep the objects internal and was only suggest this behavior for the content portion of the request

I've also had issues with receiving large requests that exceed ram. I know some other implementations must be allowing a disk cache for the actual content as it arrives. Just a guess

[btiplitz]

The processing time for the request is considerable. Do I send back a redirect and then process the request later Also could be a backup in request processing which would further delay finishing with the object but I want to say good back to the requester once I’ve committed to the journal

…

On Sat, Jun 4, 2022 at 11:46 PM Sebastiano Merlino ***@***.***> wrote: Hey @btiplitz <https://github.com/btiplitz>, thanks for the request. Can you attach a piece of code showing what you are trying to do? I am not sure why you are having to make a copy of the value unless you are modifying it before returning it. I am also not sure of what you mean by "I plan to return the response to the sender before completion" so I think an example might help to understand your use-case. The main reason the content string is currently immutable is to keep the immutability of the overall http_request object which has its advantages both in internal management of the library and to avoid unintended behaviors. Said that, I am not necessarily locked onto anything. — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGHBXNWUD5C2WH62CSUMU6TVNQPJJANCNFSM5XZYELBA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[etr]

Partially addressed in libhttpserver 2.0.0: deferred responses now let you return a response to the client before the body producer finishes (the "respond before completion" part of this request).

However, the zero-copy request-content swap you asked about — moving/swapping your own std::string into the library to avoid the copy — is not yet available; request content is still copied. Leaving this open to track the zero-copy part.