Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Feature request: data stream upload after server response
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Mon, 10 Jun 2024 13:43:30 +0200 (CEST)
On Mon, 10 Jun 2024, fungs via curl-users wrote:
> - I proposed a feature to make curl file upload work with existing HTTP
> endpoints (not mine) on existing infrastructure (cloud providers with
> managed reverse proxies and edge routers).
Sorry, but does it not already work?
> - Nowadays, it is common that requests are delegated, for instance to an
> authentication proxy, before data is uploaded to an endpoint. This is just
> how modern cloud and microservices work.
It is not really interesting nor relevant to curl exactly how many are
involved in receiving a request or answering to a response as long as protocol
is adhered to. "Delegating" in this sense does not change anything over the
wire.
> - With those setups, it does not make sense to start a data upload until an
> end to end connection has been authenticated and established, because the
> data to be passed among systems and needs to be cached in the process of
> routing. Such intermediate systems need to handle many requests and have
> storage and time limits.
I don't understand this claim. Are you suggesting that the client should
sometimes ignore the protocol mechanics because there might be someone on the
path to the end point that is acting up?
In which circumstances can the client guess that it should take shortcuts? And
exactly what shortcuts are we talking about?
> - The solution I see and which seems to work for me is to wait for the
> response before starting to upload or stream data, which ensure that all the
> infrastructure negotiation has succeeded.
I don't understand how this differs from normal behavior.
Date: Mon, 10 Jun 2024 13:43:30 +0200 (CEST)
On Mon, 10 Jun 2024, fungs via curl-users wrote:
> - I proposed a feature to make curl file upload work with existing HTTP
> endpoints (not mine) on existing infrastructure (cloud providers with
> managed reverse proxies and edge routers).
Sorry, but does it not already work?
> - Nowadays, it is common that requests are delegated, for instance to an
> authentication proxy, before data is uploaded to an endpoint. This is just
> how modern cloud and microservices work.
It is not really interesting nor relevant to curl exactly how many are
involved in receiving a request or answering to a response as long as protocol
is adhered to. "Delegating" in this sense does not change anything over the
wire.
> - With those setups, it does not make sense to start a data upload until an
> end to end connection has been authenticated and established, because the
> data to be passed among systems and needs to be cached in the process of
> routing. Such intermediate systems need to handle many requests and have
> storage and time limits.
I don't understand this claim. Are you suggesting that the client should
sometimes ignore the protocol mechanics because there might be someone on the
path to the end point that is acting up?
In which circumstances can the client guess that it should take shortcuts? And
exactly what shortcuts are we talking about?
> - The solution I see and which seems to work for me is to wait for the
> response before starting to upload or stream data, which ensure that all the
> infrastructure negotiation has succeeded.
I don't understand how this differs from normal behavior.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-06-10