From: Alexander Turenko <alexander.turenko@tarantool.org> To: Ilya Kosarev <i.kosarev@tarantool.org> Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v4 3/4] http: enrich httpc_request with curl error message buffer Date: Tue, 29 Oct 2019 02:41:56 +0300 [thread overview] Message-ID: <20191028234155.vrpomghlhjalhbiq@tkn_work_nb> (raw) In-Reply-To: <1290bf755e9e93a36be6fe0cb586b91f2d581531.1572282336.git.i.kosarev@tarantool.org> Now I don't sure whether we should add the field: the cost is increased memory footprint (it is megabytes even to 10k requests in the fly, but this will spoil caches) and so performance. Don't sure how significant cons and pros are. Anyway, my comments and thoughts are below. WBR, Alexander Turenko. > http: enrich httpc_request with curl error message buffer Try to fit the commit header into 50 symbols and concentrate on changes that are visible for a user. How about this header? | httpc: give more information is case of an error > When processing curl request error code, we are collecting error > message using curl_easy_strerror. Now we are providing more info > in errmsg, which is obtained using curl_easy_setopt with I would say: in 'errmsg' field of a response object. > CURLOPT_ERRORBUFFER option. Test case to confirm it is added. > > Closes #4578 > > @TarantoolBot document > Title: http: new field in client_object:request return table http -> httpc `client_object:request` is not valid Lua syntax: better use `client_object:request()`. > Update the documentation for client_object:request method to reflect > new field errmsg in return table. It contains extended curl request > error message obtained using CURLOPT_ERRORBUFFER option. An example about, say, your case with unsupported content encoding would shed light on why this may be needed, when a request object already contains 'reason' field. > diff --git a/src/httpc.h b/src/httpc.h > index f710b3d13..145b59929 100644 > --- a/src/httpc.h > +++ b/src/httpc.h > @@ -105,6 +105,11 @@ struct httpc_request { > int status; > /** Error message */ > const char *reason; > + /** > + * Buffer for error message obtained using > + * CURLOPT_ERRORBUFFER option. > + */ > + const char errmsg[CURL_ERROR_SIZE]; It is indented using whitespaces rather then tabulation. I'm tentative about placing 256 bytes buffer right in the structure. However the whole structure is allocated with mempool_alloc(), so maybe it is okay. Also I don't sure whether it is okay to add 256 bytes of allocated memory per request unconditionally: maybe we should provide an option to disable it for applications that have tight SLA on a response processing time. I would give Georgy necessary context (what and how we allocate in our http client now) and ask for his opinion on how and where allocate the buffer. BTW, I think that it is good to provide the field by default (in case of an error) to allow to find a cause of an error faster during development. Maybe adding this field is not the good idea if it is not cheap and need to be switched on/off case by case: AFAIR the same information can be obtained using 'verbose' flag. It would be good to catch Georgy's opinion on that too. > diff --git a/src/lua/httpc.c b/src/lua/httpc.c > index 6ed4eb788..9fb8e4801 100644 > --- a/src/lua/httpc.c > +++ b/src/lua/httpc.c > @@ -335,6 +335,10 @@ luaT_httpc_request(lua_State *L) > lua_pushstring(L, req->reason); > lua_settable(L, -3); > > + lua_pushstring(L, "errmsg"); > + lua_pushstring(L, req->errmsg); > + lua_settable(L, -3); I think we should add the field only when an error occurs. Now we add it for successful responses and it looks a bit confusing. More on that: > For earlier versions if an error code was returned but there was no > error detail then the buffer is untouched. > https://curl.haxx.se/libcurl/c/CURLOPT_ERRORBUFFER.html We should handle this case and set a buffer to an empty string before a request and verify that a code is not CURLE_OK afterwards (see the example by the link above).
next prev parent reply other threads:[~2019-10-28 23:42 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-28 17:11 [Tarantool-patches] [PATCH v4 0/4] http: add CURLOPT_ACCEPT_ENCODING option and following improvements Ilya Kosarev 2019-10-28 17:11 ` [Tarantool-patches] [PATCH v4 1/4] http: add CURLOPT_ACCEPT_ENCODING option Ilya Kosarev 2019-10-28 23:42 ` Alexander Turenko 2019-10-28 17:11 ` [Tarantool-patches] [PATCH v4 2/4] http: remove redundant & incorrect case for curl_request code Ilya Kosarev 2019-10-28 23:42 ` Alexander Turenko 2019-10-28 17:11 ` [Tarantool-patches] [PATCH v4 3/4] http: enrich httpc_request with curl error message buffer Ilya Kosarev 2019-10-28 23:41 ` Alexander Turenko [this message] 2019-11-07 12:07 ` Ilya Kosarev 2019-10-28 17:11 ` [Tarantool-patches] [PATCH v4 4/4] http: add CURLE_BAD_CONTENT_ENCODING case for curl_request code Ilya Kosarev 2019-10-28 23:42 ` Alexander Turenko 2019-10-28 23:43 ` [Tarantool-patches] [PATCH v4 0/4] http: add CURLOPT_ACCEPT_ENCODING option and following improvements Alexander Turenko 2019-11-07 12:07 ` Ilya Kosarev
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191028234155.vrpomghlhjalhbiq@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=i.kosarev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [Tarantool-patches] [PATCH v4 3/4] http: enrich httpc_request with curl error message buffer' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox