Project

General

Profile

Feature #2933

GET/HEAD with content-length

Added by Olaf-van-der-Spek 6 months ago. Updated 6 months ago.

Status:
Invalid
Priority:
Low
Assignee:
-
Category:
-
Target version:
Start date:
2019-02-09
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

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?

History

#1

Updated by gstrauss 6 months 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.

#2

Updated by Olaf-van-der-Spek 6 months 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

Also available in: Atom