Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rewrite logging #18

Open
LeSpocky opened this issue Apr 9, 2015 · 2 comments
Open

rewrite logging #18

LeSpocky opened this issue Apr 9, 2015 · 2 comments
Labels
Milestone

Comments

@LeSpocky
Copy link
Collaborator

LeSpocky commented Apr 9, 2015

Currently there's libcgi_error() which is used in numerous places around the whole library. If the global variable cgi_display_errors contains true it prints HTML markup to stdout containing the error message. If the passed error code is E_FATAL or E_MEMORY (defined in src/error.h) it even calls cgi_end() and exit().

Besides the obvious sudden exit which may be bad (do we need this?) I consider it bad to print anything to stdout where my content should go to. The used HTML tags could be invalid if not printed at the right time or even break correct markup. (They do e.g. when using sessions if there's a session cookie but no session file.)

A flexible solution could work like in libabc or we could just print to stderr, which some webservers can append to their logfiles (others return HTTP status 500 or mix stdout/stderr and return it to the browser).

@LeSpocky LeSpocky added this to the v2 milestone May 9, 2016
@LeSpocky LeSpocky added the api label May 9, 2016
@apfohl
Copy link

apfohl commented Oct 3, 2019

I really like the idea to rework the logging mechanism in the way libabc does. I want to implement this. But I would like to know if you would like to have a library context which is passed to every function or to have this globally.

Also this would fix #53 as well, right?

@LeSpocky
Copy link
Collaborator Author

LeSpocky commented Oct 3, 2019

Introducing a library handle or context would be nice in the long run, but most probably an API change and therefor topic for API v2 which would be major rework. Although not that elegant, I would opt for a solution keeping the current API for now.

I can not answer the question on error handling from the top of my head. Must look into this deeper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants