Parsing header from message to structure

[iuryr]

class Request
{
private:
  std::string _requestLine;
  std::map<std::string, std::string> _headerFields;
  std::string _body; //optional

  std::string _method;
  std::string _requestTarget;

public:
}

From RFC 9112

field-line: field-name ":" OWS field-value OWS CRLF Request can have 0 or more field-lines. Then, a CRLF

General Dynamic

• Messages are parsed using a generic algorithm, independent of the individual field names. The contents within a given field line value are not parsed until a later stage of message interpretation (usually after the message's entire field section has been processed).
• No whitespace is allowed between the field name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon. A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.
• A field line value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field line value is preferred for consistent readability by humans. The field line value does not include that leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value, or after the last non-whitespace octet of the field line value, is excluded by parsers when extracting the field line value from a field line.
• When a field name is only present once in a section, the combined "field value" for that field consists of the corresponding field line value. When a field name is repeated within a section, its combined field value consists of the list of corresponding field line values within that section, concatenated in order, with each field line value separated by a comma. For example, this section: Example-Field: Foo, Bar Example-Field: Baz contains two field lines, both with the field name "Example-Field". The first field line has a field line value of "Foo, Bar", while the second field line value is "Baz". The field value for "Example-Field" is the list "Foo, Bar, Baz".

[iuryr]

Considerando a sintaxe field-name: field-value, sabemos que, ao parsearmos field-value, devemos ignorar tanto espaços antecedentes e posteriores.

Na situação field-name: field-value1 field-value2, devemos guardar um único elemento, INCLUINDO os espaçoes entre field-value1 e field-value2.

Tratamento especial:

• Content-Length: 1*DIGIT -> somente digitos, não há espaços
• Host: segue a norma de uri-host (seja lá o que isso for)

[iuryr]

Fluxo geral: 1.Utilizar getNextLineRN para capturar o resto da linha depois do \:

2. Procurar por vírgulas -> cada vírgula separa um elemento
3. Para cada elemento, ignorar espaços (incluindo htab) iniciais e finais. Os intermediários são parte do elemento.
4. Guardar o elemento no map.
5. Se houver mais de um elemento por field-name, o segundo elemento é concatenado ao primeiro sendo separado por vírgula

Obs: pensar numa maneira de "ignorar" vírgulas que estão dentro de aspas. Por exemplo em Date

[iuryr]

TODO

• [x] Study and implement the checks of CR character not followed by LF.
• [ ] List situation where some header names cannot be repeated;
• [ ] Check for server-wide maximum values of some header-names;

---

NEXT

• Check if Content-Length value is a single decimal number. If not, return bad request;