HTP  0.5
Data Fields
htp_mpartp_t Struct Reference

#include <htp_multipart_private.h>

Data Fields

htp_multipart_t multipart
 
htp_cfg_tcfg
 
int extract_files
 
int extract_limit
 
char * extract_dir
 
int file_count
 
int(* handle_data )(htp_mpartp_t *mpartp, const unsigned char *data, size_t len, int line_end)
 
int(* handle_boundary )(htp_mpartp_t *mpartp)
 
enum htp_multipart_state_t parser_state
 
size_t boundary_match_pos
 
htp_multipart_part_tcurrent_part
 
enum htp_part_mode_t current_part_mode
 
bstr_builder_tboundary_pieces
 
bstr_builder_tpart_header_pieces
 
bstrpending_header_line
 
bstr_builder_tpart_data_pieces
 
size_t boundary_candidate_pos
 
int cr_aside
 
int gave_up_data
 

Field Documentation

size_t htp_mpartp_t::boundary_candidate_pos

The offset of the current boundary candidate, relative to the most recent data chunk (first unprocessed chunk of data).

size_t htp_mpartp_t::boundary_match_pos

Keeps track of the current position in the boundary matching progress. When this field reaches boundary_len, we have a boundary match.

bstr_builder_t* htp_mpartp_t::boundary_pieces

Used for buffering when a potential boundary is fragmented across many input data buffers. On a match, the data stored here is discarded. When there is no match, the buffer is processed as data (belonging to the currently active part).

htp_cfg_t* htp_mpartp_t::cfg
int htp_mpartp_t::cr_aside

When we encounter a CR as the last byte in a buffer, we don't know if the byte is part of a CRLF combination. If it is, then the CR might be a part of a boundary. But if it is not, it's current part's data. Because we know how to handle everything before the CR, we do, and we use this flag to indicate that a CR byte is effectively being buffered. This is probably a case of premature optimization, but I am going to leave it in for now.

htp_multipart_part_t* htp_mpartp_t::current_part

Pointer to the part that is currently being processed.

enum htp_part_mode_t htp_mpartp_t::current_part_mode

This parser consists of two layers: the outer layer is charged with finding parts, and the internal layer handles part data. There is an interesting interaction between the two parsers. Because the outer layer is seeing every line (it has to, in order to test for boundaries), it also effectively also splits input into lines. The inner parser deals with two areas: first is the headers, which are line based, followed by binary data. When parsing headers, the inner parser can reuse the lines identified by the outer parser. In this variable we keep the current parsing mode of the part, which helps us process input data more efficiently. The possible values are MULTIPART_MODE_LINE and MULTIPART_MODE_DATA.

char* htp_mpartp_t::extract_dir
int htp_mpartp_t::extract_files
int htp_mpartp_t::extract_limit
int htp_mpartp_t::file_count
int htp_mpartp_t::gave_up_data

When set, indicates that this parser no longer owns names and values of MULTIPART_PART_TEXT parts. It is used to avoid data duplication when the parser is used by LibHTP internally.

int(* htp_mpartp_t::handle_boundary)(htp_mpartp_t *mpartp)
int(* htp_mpartp_t::handle_data)(htp_mpartp_t *mpartp, const unsigned char *data, size_t len, int line_end)
htp_multipart_t htp_mpartp_t::multipart
enum htp_multipart_state_t htp_mpartp_t::parser_state

Parser state; one of MULTIPART_STATE_* constants.

bstr_builder_t* htp_mpartp_t::part_data_pieces

Stores text part pieces until the entire part is seen, at which point the pieces are assembled into a single buffer, and the builder cleared.

bstr_builder_t* htp_mpartp_t::part_header_pieces
bstr* htp_mpartp_t::pending_header_line

The documentation for this struct was generated from the following file: