Skip to content

Add support for ICAP#128

Closed
r-bk wants to merge 3 commits intoseanmonstar:masterfrom
r-bk:icap-pr2
Closed

Add support for ICAP#128
r-bk wants to merge 3 commits intoseanmonstar:masterfrom
r-bk:icap-pr2

Conversation

@r-bk
Copy link

@r-bk r-bk commented Nov 25, 2022

This PR adds support for the ICAP protocol.
More elaborate explanation is in the commit messages.

r-bk added 3 commits November 25, 2022 17:29
Description
-----------

The ICAP protocol is defined in RFC 3507 [1].

Encoding of ICAP messages is very similar to that of HTTP.
The generic structure of both ICAP and HTTP messages originates in RFC
822 (obsoleted by RFC 2822). Except for the generic structure, ICAP leans
to the HTTP specification to encode the request/status lines, headers and
chunked transfer-encoding for the message body. Hence, an HTTP parser
can be used to parse an ICAP request/response headers, assuming the ICAP
protocol version and URI scheme are properly handled. Moreover, as ICAP
protocol deals with adaptation of HTTP messages, it makes a lot of sense
to use the same crate to parse both ICAP messages and HTTP messages
embedded in the body of ICAP messages.

This commit adds a new crate feature `icap` which enables support for
parsing ICAP messages. When enabled, `httparse` accepts the ICAP version
`ICAP/1.0` where an HTTP version is expected.

A parsed request/response of an ICAP message can be differentiated by the
version number. For ICAP the minor protocol version is incremented by 100.
In other words, the ICAP/1.0 protocol is denoted by version 100. While the
HTTP/1.0 protocol is denoted by 0.

Notes
-----

The `expect2!` macro was added to support MSRV 1.39.
It is not needed starting from `rustc 1.53.0`, which has added support for
Or patterns [2]. Using Or patterns the existing `expect!` macro can be used
as follows:

```
expect!(bytes.next() == (b'H'|b'I') => Err(Error::Version));
```

[1] https://www.rfc-editor.org/rfc/rfc3507.html
[2] https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html#or-patterns
Till now the `--all-features` flag was not required, because the only
feature `std` was enabled by default.

Now, with addition of the `icap` feature, we need to add the
`--all-features` flag explicitly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant