Re: [PATCH] http: parse HTTP headers case-insensitive

[Glenn Washburn]

On Fri, 14 Jan 2022 22:20:17 +0100
Jamo <jamofer@gmail.com> wrote:

> According to https://www.ietf.org/rfc/rfc2616.txt 4.2, header names
> shall be case insensitive and we are now forced to read headers like
> `Content-Length` capitalized.

I'm not sure if Daniel likes these backticks, perhaps normal quotes
would be better. I'll let him chime in if so.

> 
> The problem with that is when a HTTP server responds with a
> `content-length` header in lowercase GRUB gets stuck because HTTP

There should be a ',' right after "lowercase". 

> module doesn't know the length of the transmision and the call never

Just noticed that "transmision" should be spelled "transmission".

> ends.
> ---
>  grub-core/net/http.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/grub-core/net/http.c b/grub-core/net/http.c
> index b616cf40b..d3ba8c799 100644
> --- a/grub-core/net/http.c
> +++ b/grub-core/net/http.c
> @@ -130,7 +130,7 @@ parse_line (grub_file_t file, http_data_t data, char 
> *ptr, grub_size_t len)
>        data->first_line_recv = 1;
>        return GRUB_ERR_NONE;
>      }
> -  if (grub_memcmp (ptr, "Content-Length: ", sizeof ("Content-Length: ") - 1)
> +  if (grub_strncasecmp (ptr, "Content-Length: ", sizeof ("Content-Length: ") 
> - 1)
>        == 0 && !data->size_recv)
>      {
>        ptr += sizeof ("Content-Length: ") - 1;
> @@ -138,8 +138,8 @@ parse_line (grub_file_t file, http_data_t data, char 
> *ptr, grub_size_t len)
>        data->size_recv = 1;
>        return GRUB_ERR_NONE;
>      }
> -  if (grub_memcmp (ptr, "Transfer-Encoding: chunked",
> -                sizeof ("Transfer-Encoding: chunked") - 1) == 0)
> +  if (grub_strncasecmp (ptr, "Transfer-Encoding: chunked",
> +                     sizeof ("Transfer-Encoding: chunked") - 1) == 0)
>      {
>        data->chunked = 1;
>        return GRUB_ERR_NONE;

Aside from the minor stuff in the commit message, the patch looks good
to me.

Reviewed-by: Glenn Washburn <development@efficientek.com>

Glenn