URL:
https://github.com/SSSD/sssd/pull/152
Title: #152: Add a tevent wrapper around libcurl's asynchronous interface
pbrezina commented:
"""
On 03/14/2017 12:19 PM, Jakub Hrozek wrote:
On Tue, Mar 14, 2017 at 03:22:19AM -0700, Pavel Březina wrote:
> The changes looks good, although I would say that disabling `Expect:
> 100-continue` is not the way to go in a long-term.
Would you prefer if this wasn't directly in the tcurl layer, but only in
the callers to keep the tcurl layer generic?
No, given the use case we can keep it there.
> I believe the problem lies
> in `secrets` responder that does not handle this properly. I agree
that the
> responder is not supposed to be a full HTTP server, however given the fact
> that this is default behavior of `libcurl` we should implement it (later).
Right, so the purpose of the Expect 100: Continue is to send the request
without the (potentially large) POST data, let the server validate the
request and if it's invalid, let it reply with an error code. If the
request is valid, let it send 100: Continue which triggers sending the
data to the server.
Which is why there was the potential timeout, libcurl was waiting for
the 100: continue which never came..
Yes. And because libcurl will be used by users in their programs to
communicate with secrets responder we should document it for the moment
and fix it in some future version.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/152#issuecomment-286401298