CustomRequestLog support for NCSA format is odd when it comes to bad requests
- Dominant language
- Java
- Stars
- 4.1k
- Forks
- 2k
- Avg merge
- 3d 56m
- Merged PRs (30d)
- 48
Description
**Jetty version(s)**
12.0.14
**Jetty Environment**
Any
**Java version/vendor** `(use: java -version)`
Any
**OS type/version**
Any
**Description**
When reviewing PR #12420 it was noticed that the portion of the NCSA format that means "the first line of the HTTP request" isn't being handled properly in case of errors.
We wind up with `BAD /badMessage HTTP/1.0` instead of the actual first line of the HTTP request.
I realize this isn't a thing in HTTP/2 and HTTP/3, but for HTTP/1.x we should strive to accomplish that properly.
The definition of NCSA combined format can be defined like this ...
```
%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i"
%h: the client hostname or IP address
%l: the client identifier or - if none is set
%u: the username used by the client for authentication or - if none is set
%t: the date and time of the HTTP request
%r: the first line of the HTTP request
%s: the status code of the HTTP response
%b: the byte size of the HTTP response
%{Referer}i: the URL that linked to the requested page or - if none is set
%{User-agent}i: the web browser and platform used by the client
```
This is the structure that NCSA tooling (like varnish) uses when it parses the already produced NCSA request log.
Contributor guide
Research direction
Start by reviewing PR #12420 and the CustomRequestLog handling for the NCSA `%r` field. Reproduce an HTTP/1.x bad request and trace how its first request line reaches the log output. Done means the log records the actual first line rather than `BAD /badMessage HTTP/1.0` while preserving the NCSA format.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100