mkmik opened a new issue, #4270:
URL: https://github.com/apache/arrow-rs/issues/4270

   **Describe the bug**
   
   `flight_sql_client --header "key: value"` issues a request with a grpc 
metadata entry whose value contains a leading whitespace, i.e. `" value`" 
instead of `"value"`.
   
   **To Reproduce**
   
   ```console
   $ flight_sql_client --host localhost  --port 8082 --headers 'database: foo' 
'select * from bobby'
   ... Error: database  foo not found
   ```
   
   **Expected behavior**
   
   The server should receive a header/metadata with a key containing the 
`"database"` string and a value containing the `"foo"` string.
   
   The server instead receives a value containing the `" foo"` string.
   
   **Additional context**
   
   While the HTTP/1.1 clearly states that the value in a whitespace leading to 
the header value must be ignored, in HTTP2 the header key and value are clearly 
delimited in the binary protocol and whitespace is not inherently ignore
   
   The [gRPC 
spec](https://chromium.googlesource.com/external/github.com/grpc/grpc/+/HEAD/doc/PROTOCOL-HTTP2.md)
 states that the header (aka metadata) value should not have leading or 
trailing whitespace.
   
   > ASCII-Value should not have leading or trailing whitespace. If it contains 
leading or trailing whitespace, it may be stripped. 
   
   At least some gRPC libraries (such as Tonic) don't strip the leading 
whitespace.
   
   I think these libraries are correct, since the leading whitespace is purely 
an artifact of a string encoding of the key+value pair, when  encoded in a 
HTTP/1.1-like way (i.e. "foo: value").
   
   Unfortunately this encoding is very common and people are very used to it. 
It's used in many tools such as `curl` and even `grpcurl`.
   
   In fact `grpcurl -H "database: foo"` will correctly set `key = "database"` 
and `value = "foo` when setting the metadata fields.
   
   (I checked that with wireshark and with a dummy gRPC server)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to