Project

General

Profile

Actions

Bug #2986

closed

Cookie format specifier is broken

Added by xoneca over 4 years ago. Updated over 4 years ago.

Status:
Fixed
Priority:
Normal
Category:
mod_accesslog
Target version:
ASK QUESTIONS IN Forums:

Description

The %{name}C format specifier doesn't log cookie value correctly.

Example request with header:

Cookie: test1=1; test2=2; test3=3

Using following configuration:

accesslog.format = "[%{test1}C][%{test2}C][%{test3}C]" 

test1 cookie value gets logged, but test2 and test3 don't:

[1][][]

Files

Actions #2

Updated by xoneca over 4 years ago

Sorry, I overlooked the removal of the last line in the patch. I've reworked the patch.

Actions #3

Updated by gstrauss over 4 years ago

Thanks. I'll try to review this patch later this week.

Actions #4

Updated by gstrauss over 4 years ago

This appears to preserve the existing behavior of how whitespace is handled, and also fixes the issue you are seeing:

--- a/src/mod_accesslog.c
+++ b/src/mod_accesslog.c
@@ -1098,7 +1098,7 @@ REQUESTDONE_FUNC(log_access_write) {
                                                        buffer_free(bstr);
                                                        break;
                                                } else {
-                                                       do { ++str; } while (*str != ' ' && *str != '\t' && *str != '\0');
+                                                       do { ++str; } while (*str != ';' && *str != ' ' && *str != '\t' && *str != '\0');
                                                }
                                                while (*str == ' ' || *str == '\t') ++str;
                                        } while (*str++ == ';');

Actions #5

Updated by xoneca over 4 years ago

Sure, fix as you wish.

Your proposed change has a couple edge cases, though: an empty cookie (i.e. two semicolons in a row), skips the next cookie. And if the cookie value starts with semicolon and space, no cookies are read. These are very edge cases, so I can live with them :)

You don't have to be concernet with the witespace behaviour of my patch: whitespace is implicitly skipped as we only care to find the next semicolon. Indeed, could have used strchrnul to find the next semicolon, instead of the while loop.

Actions #6

Updated by xoneca over 4 years ago

I wasn't sure, but it seems empty cookies are allowed by the RFC [1]:

   4.  Serialize the cookie-list into a cookie-string by processing each
       cookie in the cookie-list in order:

       1.  Output the cookie's name, the %x3D ("=") character, and the
           cookie's value.

-->    2.  If there is an unprocessed cookie in the cookie-list, output
-->        the characters %x3B and %x20 ("; ").

[1] https://tools.ietf.org/html/rfc6265#section-5.4

Actions #7

Updated by xoneca over 4 years ago

Patch using strchrnul instead of a while loop. Tested with all discussed edge cases.

Actions #8

Updated by gstrauss over 4 years ago

strchrnul() is a GNU extension and is not as portable as C or POSIX standard library calls.

Actions #9

Updated by gstrauss over 4 years ago

--- a/src/mod_accesslog.c
+++ b/src/mod_accesslog.c
@@ -1098,7 +1098,7 @@ REQUESTDONE_FUNC(log_access_write) {
                                                        buffer_free(bstr);
                                                        break;
                                                } else {
-                                                       do { ++str; } while (*str != ' ' && *str != '\t' && *str != '\0');
+                                                       while (*str != ';' && *str != ' ' && *str != '\t' && *str != '\0') ++str;
                                                }
                                                while (*str == ' ' || *str == '\t') ++str;
                                        } while (*str++ == ';');
Actions #10

Updated by gstrauss over 4 years ago

  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.55
Actions #11

Updated by gstrauss over 4 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100
Actions

Also available in: Atom