Closed mogul closed 1 year ago
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.
The labels on this github issue will be updated when the story is started.
- This would be clearer with an example. Please add at least one.
I refrained from adding one because unlike the error_log
directive, which can appear at the top level of nginx.conf
, the specification for the access_log
directive differs between the NGINX modules that implement it. For example, compare the stream
module to the http
module. The directive will look different depending on where you're adding it in the nginx.conf
file.
- If you can't include the list of values for "format," you at least need to provide a couple of examples of what format values are valid.
Again, the fields available for logging vary for each NGINX module, and are also user-customizable. For example the specification for log_format
in the http
module is pretty large and provides an implicit default of combined
while the stream version is also complex but there's less available and the format has to be explicitly specified and referenced. I don't want to just reproduce NGINX documentation here if at all possible. Is it permissible to link out to the nginx.org site?
- It looks like "Syntax" is part of the command. Is this correct?
I was only following the structure already set by the error_log
example already in place.
- It would be clearer to show file as . This shows that "file" will be replaced by the filename. An example can help show that the filename can include its path (if that is possible).
Sorry, I'm not clear what you're asking here. Can you make a comment on the particular line, and use the +/-
button in GitHub's editor to show me what you think should be different?
In summary: All I really want to get across is that /dev/stdout
is a valid file target for logging, whether via error_log
(which is already touched upon) or via access_log
(which was conspicuously left out). If you can think of a more compact way to express that, then I'll happily take that and rescind this PR!
Made some updates... Can you take another look?
Nice work!
Previously there was no documentation of the fact that
/dev/stdout
was a valid logging target.