Project

General

Profile

Actions

Feature #2933

closed

GET/HEAD with content-length

Added by Olaf-van-der-Spek about 5 years ago. Updated about 5 years ago.

Status:
Invalid
Priority:
Low
Category:
-
Target version:
ASK QUESTIONS IN Forums:

Description

(request.c.1163) GET/HEAD with content-length -> 400

I've got quite a few of these in my logs. Does it make sense to log these?
If yes, some more info like IP and UA would be handy.
If not, could you stop logging them?

Actions #1

Updated by gstrauss about 5 years ago

  • Status changed from New to Invalid

(request.c.1163) GET/HEAD with content-length -> 400

I've got quite a few of these in my logs. Does it make sense to log these?

https://tools.ietf.org/html/rfc7231#section-4.3.1
4.3.1. GET
...
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

https://tools.ietf.org/html/rfc7231#section-4.3.2
4.3.2. HEAD
...
A payload within a HEAD request message has no defined semantics;
sending a payload body on a HEAD request might cause some existing
implementations to reject the request.

.

If yes, some more info like IP and UA would be handy.

There is already an option to log Content-Length in mod_accesslog, as there are for IP and User-Agent.

If not, could you stop logging them?

Similar to numerous other places logging errors during request processing, I may consider logging this only if debug.log-request-header-on-error = "enable" . This may or may not occur as a side effect of my refactoring of the request processing code.

Actions #2

Updated by Olaf-van-der-Spek about 5 years ago

gstrauss wrote:

(request.c.1163) GET/HEAD with content-length -> 400

I've got quite a few of these in my logs. Does it make sense to log these?

...

Is that a yes or a no? ;)

If yes, some more info like IP and UA would be handy.

There is already an option to log Content-Length in mod_accesslog, as there are for IP and User-Agent.

This is about error.log, not access.log.

If not, could you stop logging them?

Similar to numerous other places logging errors during request processing, I may consider logging this only if debug.log-request-header-on-error = "enable" . This may or may not occur as a side effect of my refactoring of the request processing code.

Great

Actions

Also available in: Atom