fix(uri): update path and query validation to reject DEL character

[HaiqalAly]

Hello! 👋

This is made to address #820 bug reports where the http crate was accidentally allowing the raw ASCII DEL control character (0x7F) in URI paths and queries.

What was happening?

Before, the crate correctly allows raw UTF-8 characters in the path and query. To do this, the parser checks if a byte is in the range 0x7F..=0xFF and flags it to be validated as UTF-8 later.

But, 0x7F is the DEL control character! Because it's a valid 1-byte ASCII/UTF-8 character, it was passing the UTF-8 validation step and sneaking its way into the parsed URI.

Proposed solution

I updated the byte range checks from 0x7F..=0xFF to 0x80..=0xFF.

• 0x80 through 0xFF correctly captures all multi-byte UTF-8 sequences.
• 0x7F now falls through to the default _ => return Err(...) arm, properly rejecting it as an invalid URI character just like the other ASCII control characters (0x00 - 0x1F).

I also added two new tests (rejects_del_in_path and rejects_del_in_query) to make sure this stays fixed!

Notes

This is technically a breaking change for any older clients that were incorrectly relying on sending raw, unescaped DEL characters in their URIs. According to the RFC 3986 spec, control characters are strictly forbidden from appearing unescaped. If a client needs to send a DEL character, they must percent-encode it as %7F.

Let me know if you need any changes or if this is intentional!