Your suggestion has merit, i'm just trying to discuss what the end result should look like. :-) We need to tread carefully so that we don't break the NCSA access log syntax for the other tooling that utilizes that syntax.
I would hope that a generic "access log upgrade requests" can be done in the location where Upgrade requests are performed now. Currently the access log does not log any old header (just user-agent and optionally cookies). The scheme used is unavailable, but perhaps "Upgrade" header can be logged? Joakim Erdfelt / [email protected] On Thu, Jun 8, 2017 at 7:10 AM, anurag gupta <[email protected]> wrote: > Thanks for the information Joakim, > > I'm interested in ws/wss, headers, request path, response code (specially > for error scenarios). > > Is the following method suitable for placing the log line ? > > public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest > request, HandshakeResponse response) {} > > I was hoping to do it in a configurable way. > > Can you suggest some better way ? > > > > > On Thu, Jun 8, 2017 at 7:18 PM, Joakim Erdfelt <[email protected]> wrote: > >> Explaining what's going on now ... >> >> Access log, aka NCSA Request Log is for logging of HTTP requests. >> It has the distinction of logging not only the request details, but also >> the response details (status code, latency, size, etc). >> This is done when the HTTP response is completed. >> >> A websocket upgrade is an HTTP Request + a partial HTTP Response, after >> which it is no longer HTTP. >> Said another way, when the WebSocket Handshake Response is completed, the >> connection is no longer HTTP. >> The HTTP Response is never completed, hence no NCSA Request Log entry. >> >> Now, if we add support for this, what would you expect in the access log? >> >> What I would expect ... >> >> GET request on a path, response code 101, latency at -1, size at -1. (is >> this actually useful?) >> >> You would be missing the fact that its ws:// or wss:// (it could have >> been an http/2 upgrade for all that the access log format supports) >> >> The negotiated websocket sub-protocol would also be absent in the access >> log. (we would probably need to add support for >> https://github.com/eclipse/jetty.project/issues/113) >> >> >> Joakim Erdfelt / [email protected] >> >> On Thu, Jun 8, 2017 at 6:04 AM, anurag gupta <[email protected]> >> wrote: >> >>> Hi there, >>> >>> I'm using Jetty 9.4.3.v20170317 for running a websocket server. I was >>> able to configure request logging, that works great for normal HTTP >>> requests. But it seems websocket upgrade requests are not logged at all. >>> >>> How to configure it ? >>> >>> -- >>> Regards >>> Anurag >>> >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > > -- > Regards > Anurag > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
