Suricata

libhtp doesn't provide this info:

htp_tx_generate_response_headers_raw: data len 35 (0x23)
00000000  44 61 74 65 3a 20 54 68  75 2c 20 32 32 20 44 65  |Date: Thu, 22 De|
00000010  63 20 32 30 31 31 20 32  30 3a 35 32 3a 34 35 20  |c 2011 20:52:45 |
00000020  47 4d 54                                          |GMT|

htp_tx_generate_response_headers_raw: data len 14 (0xe)
00000000  53 65 72 76 65 72 3a 20  41 70 61 63 68 65        |Server: Apache|

htp_tx_generate_response_headers_raw: data len 19 (0x13)
00000000  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  |Content-Length: |
00000010  32 37 32                                          |272|

htp_tx_generate_response_headers_raw: data len 43 (0x2b)
00000000  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 74 65  |Content-Type: te|
00000010  78 74 2f 68 74 6d 6c 3b  20 63 68 61 72 73 65 74  |xt/html; charset|
00000020  3d 69 73 6f 2d 38 38 35  39 2d 31                 |=iso-8859-1|

So Suricata doesn't use it to create the http_raw_buffer

 0000  44 61 74 65 3A 20 54 68  75 2C 20 32 32 20 44 65   Date: Th u, 22 De
 0010  63 20 32 30 31 31 20 32  30 3A 35 32 3A 34 35 20   c 2011 2 0:52:45
 0020  47 4D 54 53 65 72 76 65  72 3A 20 41 70 61 63 68   GMTServe r: Apach
 0030  65 43 6F 6E 74 65 6E 74  2D 4C 65 6E 67 74 68 3A   eContent -Length:
 0040  20 32 37 32 43 6F 6E 74  65 6E 74 2D 54 79 70 65    272Cont ent-Type
 0050  3A 20 74 65 78 74 2F 68  74 6D 6C 3B 20 63 68 61   : text/h tml; cha
 0060  72 73 65 74 3D 69 73 6F  2D 38 38 35 39 2D 31      rset=iso -8859-1

libhtp calls htp_chomp before storing the header line. htp_chomp removed 0a and 0d characters from the buffer.

Potential solutions:
- keep these chars in the buffer
- add a separate buffer for the 0d 0a chars that can be used to reconstruct the original line

Talking to libhtp upstream about this.