On 26/08/2016 5:43 a.m., Alex Rousskov wrote:
> On 08/25/2016 10:26 AM, Amos Jeffries wrote:
>> About
>> the only further optimization we can do there is make the
>> "CharacterSet::SP" that it outputs in the sensitive path be a local
>> static *within* DelimiterCharacters() itself and return a
On 08/25/2016 10:26 AM, Amos Jeffries wrote:
> About
> the only further optimization we can do there is make the
> "CharacterSet::SP" that it outputs in the sensitive path be a local
> static *within* DelimiterCharacters() itself and return a reference to
> that instead of constructing a new
On 08/25/2016 10:26 AM, Amos Jeffries wrote:
> 2016-08-23 17:50 GMT+03:00 Alex Rousskov:
>> I wonder whether we should make this variable static to avoid repeated
>> function calls on a performance-sensitive code path.
> The output of DelimiterCharacters() cannot be stored in a static because
>
On 25/08/2016 11:31 a.m., Eduard Bagdasaryan wrote:
> 2016-08-23 17:50 GMT+03:00 Alex Rousskov:
>
>> s/request-line/request-line: URI/ for consistency and clarity sake.
>
>> I wonder whether we should make this variable static to avoid repeated
>> function calls on a performance-sensitive code
2016-08-23 17:50 GMT+03:00 Alex Rousskov :
> s/request-line/request-line: URI/ for consistency and clarity sake.
> I wonder whether we should make this variable static to avoid repeated
> function calls on a performance-sensitive code path. Same for the old
>
On 08/24/2016 08:30 AM, Amos Jeffries wrote:
> On 25/08/2016 12:36 a.m., Eduard Bagdasaryan wrote:
>> 2016-08-23 18:01 GMT+03:00 Alex Rousskov:
>>
>>> invalid request-line: missing delimiter before "HTTP/1"
>>
>> In order to generate "where" with such detalization (i.e. the specific
>> protocol
On 25/08/2016 12:36 a.m., Eduard Bagdasaryan wrote:
> 2016-08-23 18:01 GMT+03:00 Alex Rousskov:
>
>> invalid request-line: missing delimiter before "HTTP/1"
>
> In order to generate "where" with such detalization (i.e. the specific
> protocol version or method) we would need to pass
On 08/24/2016 06:36 AM, Eduard Bagdasaryan wrote:
> 2016-08-23 18:01 GMT+03:00 Alex Rousskov
> :
>
>> invalid request-line: missing delimiter before "HTTP/1"
>
> In order to generate "where" with such detalization (i.e. the specific
> protocol version or method)
2016-08-23 18:01 GMT+03:00 Alex Rousskov :
> invalid request-line: missing delimiter before "HTTP/1"
In order to generate "where" with such detalization (i.e. the specific
protocol version or method) we would need to pass skipDelimiter() the
parsed
On 08/23/2016 08:08 AM, Amos Jeffries wrote:
> A followup patch can be done to give skipDelimiter a 'const char* which'
> parameter that takes a description/name for the delimiter to improve
> that debug output.
>
> so:
> skipDelimiter(blah, "method")
>
> produces:
> invalid request-line:
On 08/23/2016 03:26 AM, Eduard Bagdasaryan wrote:
> 2016-08-23 3:08 GMT+03:00 Alex Rousskov:
>> I do not understand why you decided to use maxMethodLength in
>> parseRequestFirstLine(). AFAICT, parseMethodField() already does
>> everything we need: It logs an error message and sets parseStatusCode
On 23/08/2016 9:26 p.m., Eduard Bagdasaryan wrote:
> 2016-08-23 3:08 GMT+03:00 Alex Rousskov:
>
>> I do not understand why you decided to use maxMethodLength in
>> parseRequestFirstLine(). AFAICT, parseMethodField() already does
>> everything we need: It logs an error message and sets
2016-08-23 3:08 GMT+03:00 Alex Rousskov :
> I do not understand why you decided to use maxMethodLength in
> parseRequestFirstLine(). AFAICT, parseMethodField() already does
> everything we need: It logs an error message and sets parseStatusCode
> accordingly.
On 08/22/2016 04:24 PM, Eduard Bagdasaryan wrote:
> -// Limit to 32 characters to prevent overly long sequences of non-HTTP
> -// being sucked in before mismatch is detected. 32 is itself annoyingly
> -// big but there are methods registered by IANA that reach 17 bytes:
> -//
14 matches
Mail list logo