Request logging for web server

[ogelami]

Closes #22945
Could aid #35444, #45442

Motivation

Currently, there is no built-in way to log HTTP requests handled by the Next.js web server, whether they are serving static, SSR, or API responses. This feature is often essential for monitoring and debugging production environments. The issue requests a mechanism to enable logging of HTTP requests similar to traditional access logs.

Implementation

This PR introduces a new feature to the Next.js web server: the ability to start the server with an additional --access-log <filename> flag. When this flag is provided, the server writes HTTP request logs to the specified file in the standard access log format, e.g.,:

127.0.0.1 2024-12-31T11:36:08.516Z GET /info?_rsc=1ld0r Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Example Usage

To enable access logging, start the Next.js web server with the following command:

next start --access-log access.log

Breakings

This PR does not introduce breaking changes. It adds a new optional feature that is backwards-compatible with existing server configurations.

Benefits

• Seamless integration for production monitoring.
• No additional dependencies or middleware required.
• Simple log format for easy parsing and analysis.

[ijjk]

Allow CI Workflow Run

• approve CI run for commit: c6f9c97

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[Bharat23]

Apart from appending to a file, adding a way to output logs in stdout will be beneficial here.

[tybro0103]

@ogelami Is this able to actually get details about the response in addition to the request? I see the code is adding the response status code to the logged string, but in your example log it isn't there. Which kinda tracks with the whole HTTP streaming thing.

Assuming that works, a couple things that'd be nice:

• the duration of the request/response
• ability to pass a callback instead of only writing to a file so we can do whatever we need to do with the details

Not sure exactly the nature of how HTTP streaming complicates timing of things, but I'd assume instead of just a single duration for the request, there would be multiple durations that matter; perhaps:

• time for the first body to be sent
• time for the entire request to finish

If someone from Next could chime on their thinking on this topic that would be great - seems pretty preposterous to not be able to log status codes and response times.