mg_request_info retrieved from mg_get_request_info() should not be const

[cesanta]

mg_request_info retrieved from mg_get_request_info() should not be const

[cpq]

I see. Yeah, this case requires constness to be cast.
Out of curiosity, what it the use case of REQUEST_COMPLETE? Can't you do the work in NEW_REQUEST handler, cause you know it is going to be 304 ?

[jmucchiello]

The use case is "standardized" access logs. I write to the log twice. When new_request arrives and when request_complete arrives so I can list durations and stuff in the second log action. This applies to both requests I handle and which are handled internally (mostly images/js/css files).

Written in a format similar to Apache, I can use logging tools for Apache to examine my logs for long processes (not that I've gotten that sophisticated with it yet).

[cpq]

I see. The problem is that I am mixing two things together - request info,
which must be const, and reply info (status code).
I'd like to keep request_info const, cause that sounds right. user_data can
be taken out from there and a different call could be made,
e.g. mg_get_user_data() to retrieve it.
Not sure what to do with status code though. Ideas?
Do you thing it is cleaner to remove constness from the request_info ?

On Wed, Sep 5, 2012 at 7:15 PM, jmucchiello [email protected]:

The use case is "standardized" access logs. I write to the log twice. When
new_request arrives and when request_complete arrives so I can list
durations and stuff in the second log action. This applies to both requests
I handle and which are handled internally (mostly images/js/css files).

Written in a format similar to Apache, I can use logging tools for Apache
to examine my logs for long processes (not that I've gotten that
sophisticated with it yet).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-8308269.

[jmucchiello]

I understand wanting to make request_info const. So do I. But that status code gets in the way. Since it is just status code and user_data, you could add two APIs. A mg_get_user_data(conn) API is simple. For status_code, you may as well have it send the status_code as well: mg_send_status_code(conn, int status_code, const char* status_text).

Internally mg_send_status_code() would set the status_code in the request structure and call mg_printf with the first line HTTP response:

mg_printf("HTTP/1.1 %d %s", status_code, status_text);

I "nicer" version of such a function would supply the status_text based on the status_code but for a first run API, this should be good enough.

Ultimately it depends on how much want the request info to be const compared to how much you dislike adding APIs to mongoose.

[cpq]

Issue 15 is very relevant. Let's close this and proceed with issue 15.