Maybe everybody else understands, but I didn’t.
The 6th parameter of the MHD_start_daemon call is copied to the 1st parameter of the MHD_AccessHandlerCallback call. Every time it is called.
Since my C++ object exists until the application is shut down, and MHD_start_daemon is called from my C++ object, I can pass
this in the 6th parameter.
Below is the documentation. That I was finally able to wrap my head around.
Note parameter 1 is for the collection of requests.
Parameter 8 is for the particular request. (Multiple calls to the callback function, perhaps.)
Parameter 1 is the sixth parameter on the MHD_start_daemon call. That parameter is called dh_cls. Default handler – closure.
/**
* Main MHD callback for handling requests.
*
* @param
cls argument given together with the function
* pointer when the handler was registered with MHD
* @param connection handle identifying the incoming connection
* @param url the requested url
* @param method the HTTP method used ("GET", "PUT", etc.)
* @param version the HTTP version string (i.e. "HTTP/1.1")
* @param upload_data the data being uploaded (excluding HEADERS,
* for a POST that fits into memory and that is encoded
* with a supported encoding, the POST data will NOT be
* given in upload_data and is instead available as
* part of MHD_get_connection_values; very large POST
* data *will* be made available incrementally in
* upload_data)
* @param upload_data_size set initially to the size of the
* upload_data provided; the method must update this
* value to the number of bytes NOT processed;
* @param ptr pointer that the callback can set to some
* address and that will be preserved by MHD for future
* calls for this request; since the access handler may
* be called many times (i.e., for a PUT/POST operation
* with plenty of upload data) this allows the application
* to easily associate some request-specific state.
* If necessary, this state can be cleaned up in the
* global "MHD_RequestCompleted" callback (which
* can be set with the MHD_OPTION_NOTIFY_COMPLETED).
* Initially, <tt>*con_cls</tt> will be NULL.
* @return MHS_YES if the connection was handled successfully,
* MHS_NO if the socket must be closed due to a serios
* error while handling the request
*/
static int
create_response (void *cls,
struct MHD_Connection *connection,
const char *url,
const char *method,
const char *version,
const char *upload_data,
size_t *upload_data_size,
void **ptr)
{
struct MHD_Response *response;
struct Request *request;
From: libmicrohttpd <libmicrohttpd-bounces+address@hidden>
On Behalf Of Hedin, Richard (InfoSys)
Sent: Monday, March 25, 2019 3:21 PM
To: libmicrohttpd development and user mailinglist <address@hidden>
Subject: [EXTERNAL] [libmicrohttpd] Can pass a "this" pointer?
Hello. I have some C++ objects that can process the incoming message. The problem is that the callbacks have to be static methods. (Don’t they?) So that the callbacks don’t have access to the
this pointer.
The C++ objects will live longer than the http requests. I’m thinking I can pass the this pointer in the closure objects that MHD_start_daemon takes. But the daemon mechanism passes a null in that spot when the callback method is first
called. (Doesn’t it?)
What is a recommended way of accomplishing this?
Regards, Rick
|
|
| Get the AAA Mobile app! |
|
|
| AAA Disclaimer Communication |
| This communication (including all attachments) is intended solely for the use of the person(s) to whom it is addressed and should be treated as a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately delete it from your system and notify the originator. Your cooperation is appreciated. |