Hello wbr,
Thank you for reviewing this patch.
> On Mar 5, 2018, at 23:06, Valentin V. Bartenev <vbart@nginx.com> wrote:
>
> On Monday 05 March 2018 11:11:08 Haitao Lv wrote:
> [..]
>>> @@ -145,10 +152,6 @@ ngx_http_parse_request_line(ngx_http_request_t *r, ngx_buf_t *b)
>>> case sw_start:
>>> r->request_start = p;
>>>
>>> - if (ch == CR || ch == LF) {
>>> - break;
>>> - }
>>> -
>>
>> I think Nginx should not allow any leading \r or \n. HTTP client should never send this chars
>> before the request line. Support this feature makes the buffer management more harder.
>
> Support for this feature is required. See the notes from Ruslan.
> Some clients send additional empty line between keepalive requests.
Yes, this is a mistake. I did not read the RFC carefully. Sorry again. But this change isn't needed.
>
> [..]
>>> +#if (NGX_HTTP_V2)
>>> + case sw_h2_preface:
>>> +
>>> + if (ch == *n++) {
>>
>> I introduce a new sw_h2_preface state. In this state, the parser will check the h2 preface char by char.
>>
>> The parser only check at most 20 chars "* HTTP/2.0\r\n\r\nSM\r\n\r\n". So the buffer will not be fulfilled.
>>
>
> The recv() operation gets buffer size as an argument.
>
> Thus, the buffer can be fully filled with all the data copied from
> a socket buffer. HTTP/2 clients usually don't send preface alone.
> They can send other data with the preface.
Yes, the buffer could be full filled. HTTP/2 client will send more frames after the h2 preface, this is
why I introduce the ngx_http_v2_init_after_preface(ngx_event_t *rev, ngx_buf_t *buf).
All the remaining data in the buffer will be copied to the h2mcf->recv_buffer and be processed by the HTTP/2 ngx_http_v2_state_head handler.
So this will not breaks the HTTP/2 handshake.
However, if we received data is longer than the h2mcf->recv_buffer_size, the current patch will yield a
bad request response.
A bad case is the client_header_buffer_size(default 1k) set larger than the http2_recv_buffer_size(default 265k), we will may fully filled the header_in buffer but cannot be copied into the h2mcf->recv_buffer,
which will cause the HTTP/2 handshake failed. But simple way to workaround this issue is to change the
http2_recv_buffer_size to or larger than client_header_buffer_size. It is a hack.
>
> [..]
>>> +#if (NGX_HTTP_V2)
>>> +static void
>>> +ngx_http_process_h2_preface(ngx_event_t *rev)
>>> +{
>>> + size_t len;
>>> + ngx_connection_t *c;
>>> + ngx_http_request_t *r;
>>> + ngx_http_connection_t *hc;
>>> + ngx_http_v2_main_conf_t *h2mcf;
>>> +
>>> + c = rev->data;
>>> + r = c->data;
>>> + hc = r->http_connection;
>>> +
>>> + ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0,
>>> + "http process h2 preface");
>>> +
>>> + r->header_in->pos = r->header_in->start + 24;
>>> +
>>> + len = r->header_in->last - r->header_in->pos;
>>> +
>>> + h2mcf = ngx_http_get_module_main_conf(hc->conf_ctx, ngx_http_v2_module);
>>> +
>>> + if (len <= h2mcf->recv_buffer_size) {
>>
>> We check the recv buffer size before do the ngx_http_v2_init_after_preface.
>>
> [..]
>
> See above. It's a bad idea to decline request with a "client sent
> invalid h2 preface" message in error log just because client has
> sent more HTTP/2 frames right after the preface.
In this path, all the valid HTTP/2 handshake will never generate a error log.
>
> Overall, the patch looks like a hack and introduces too much
> complexity for this feature. While I understand the reasoning,
> the proposed implementation cannot be accepted.
Could you clarify that whether is this feature not accepted or this patch?
If this feature is not needed, I will terminate this thread.
If this patch only looks like a hack, would you like offer any advice to write
code with good smell?
Thank you.
>
> Protocol detection before starting processing HTTP/1 or HTTP/2
> could be a better way to go.
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
