refactor: use foreign-type for request

[ensh63]

Proposed changes

foreign_type::ForeignTypeRef trait is used to define Request object. While generally the use of this object almost unchanged, reference trait allows to avoid unnecessary copying of original ngx_http_request_t data.

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have written my commit messages in the Conventional Commits format.
• I have read the CONTRIBUTING doc
• I have checked that all unit tests pass after adding my changes
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

[Copilot]

Pull Request Overview

This PR refactors the Request struct to use the foreign_types::ForeignTypeRef trait instead of direct wrapper implementation. This change allows the Request object to avoid unnecessary copying of original ngx_http_request_t data by using a reference-based approach.

Key changes:

• Replace direct struct wrapping with ForeignTypeRef trait implementation
• Update all macro call sites to use ForeignTypeRef::from_ptr_mut() instead of custom conversion
• Add foreign-types dependency to enable the new pattern

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/http/request.rs	Refactored Request struct to implement ForeignTypeRef trait and updated all field access to use helper methods
src/http/upstream.rs	Updated macro to use ForeignTypeRef::from_ptr_mut() for request conversion
src/core/mod.rs	Added re-export of ForeignTypeRef trait
examples/upstream.rs	Updated example to use new ForeignTypeRef pattern and added import
examples/async.rs	Updated async example to use ForeignTypeRef conversion methods
Cargo.toml	Added foreign-types dependency

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[pchickey]

I agree that Request(ngx_http_request_t) was the wrong representation. I was going to propose that we make it Request(NonNull<ngx_http_request_t>) with a constructor fn from_http_request(NonNull<ngx_http_request_t>) -> Self and not use any &mut self methods, because nginx does not consider any *mut ngx_http_request_t to be unique, and the uniqueness property of Request does not make its use any more or less unsafe.

[xeioex]

LGTM.

[ensh63]

Closed because there are no meaningful changes in this PR.

[pchickey]

@ensh63 would you like me to work on a PR based on this rough sketch? #211 (review)

[bavshin-f5]

I don't believe Request(NonNull<ngx_http_request_t>) is a better direction. It is certainly more convenient if you need to store the request object, handle it in asynchronous callbacks and crash when the pointer is stale, but it might be less safe than the current state.

It's not a new problem, and I've been looking at the various approaches.
One of the ideas I wanted to explore is indexed pointers (or at least I think that's the name. It is bad for any kind of search, and I lost the link to the paper). In essence, it is an indirection via slotmap, where the entries are invalidated from ngx_http_request_t destructor. It should solve UAF, and we can add some RefCells on top to assert unique access.