client
client copied to clipboard
knative
--log-http shouldn't write to stderr
When using --log-http it would be nice if it didn't write the log to stderr, but appended to a file (either well-defined name, or value specified by the user). Having that output appear mixed in with the normal output makes it harder to parse/extract. Often I might turn on this option when running a set of scripts so I can decide later if I want to debug it by looking at the http flows. Having all of this output mixed in with the normal output makes it much harder to process.
+1 for value specified by the user. We could use existing flag to decide
- dont print http-logs --->
--log-httpnot specified - print to a file --->
--log-httpspecified with a filename - print with command output --->
--log-httpspecified without any value
If the http request response to be appended in a file, it would be good if kn command invoked can be written before the request and response, should be useful to identify the kn command and respective request-response (script use case).
it would be good if kn command invoked can be written before the request and response
yep!
@akerekes Thanks a lot for taking over this issue, but I'm not 100% sold that we need this feature that way. Sorry I forgot about this issue (it has been some time).
See my comment at https://github.com/knative/client/pull/683#pullrequestreview-361700746
My main point is, (a) HTTP logging with body is broken currently (for every sync operation involving a watch, see #485) and (b) we should strive for a more comprehensive solution as described in #333 which makes --log-http obsolete.
Also, I'm not sure that we really deal with log files (which has its own difficulties in case of errors), as we are CLI tool and not a background service. IMO we should all write to stdout, stderr or maybe a custom file descriptor (>2), but let the user decide what todo.
One solution would be to use unique prefixes for the output on which people can grep & tee to create their own logging.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.