Skip to content

Add a model and parser for the RFC 9209 Proxy-Status response field - #689

Closed
arturobernalg wants to merge 1 commit into
apache:masterfrom
arturobernalg:rfc9209-proxy-status
Closed

Add a model and parser for the RFC 9209 Proxy-Status response field#689
arturobernalg wants to merge 1 commit into
apache:masterfrom
arturobernalg:rfc9209-proxy-status

Conversation

@arturobernalg

Copy link
Copy Markdown
Member

Proxy-Status is a Structured Fields (RFC 8941) List whose members carry an intermediary identity and a set of parameters. ProxyStatus is an immutable holder for a single member, ProxyStatusError enumerates the standardized error tokens, and ProxyStatusSupport parses the field value. Parameter values keep their structured-field types, the standardized and error-specific parameter types are validated, received-status is checked as an HTTP status code, and byte-sequence values are defensively copied. The code only decodes the field; it neither interprets nor acts on the reported values.

Proxy-Status is a Structured Fields (RFC 8941) List whose members carry an intermediary identity and a set of parameters. ProxyStatus is an immutable holder for a single member, ProxyStatusError enumerates the standardized error tokens, and ProxyStatusSupport parses the field value. Parameter values keep their structured-field types, the standardized and error-specific parameter types are validated, received-status is checked as an HTTP status code, and byte-sequence values are defensively copied. The code only decodes the field; it neither interprets nor acts on the reported values.
@arturobernalg
arturobernalg requested a review from ok2c August 15, 2026 16:47
*/
public static List<ProxyStatus> parse(final CharSequence value) throws ParseException {
Args.notNull(value, "Proxy-Status value");
final ParserCursor cursor = new ParserCursor(0, value.length());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arturobernalg Keep it flexible and pass ParserCursor as a parameter. That would enable the parse message to take its input from directly FormattedHeader without having to make an intermediate String out of it.

See MessageSupport#parserHeaderValue

@ok2c

ok2c commented Aug 18, 2026

Copy link
Copy Markdown
Member

@arturobernalg Overall, what is your plan for this code? Is this something that you need at work or for a private project? I do not see this code applicable anywhere in neither core or client at the moment. What is the plan?

@arturobernalg

Copy link
Copy Markdown
Member Author

Overall, what is your plan for this code? Is this something that you need at work or for a private project? I do not see this code applicable anywhere in neither core or client at the moment. What is the plan?

It is not for a specific work or private project. My intention was to add RFC 9209 support incrementally. I started with Core because the field syntax and model are generic HTTP semantics rather than client policy.

@ok2c

ok2c commented Aug 18, 2026

Copy link
Copy Markdown
Member

Overall, what is your plan for this code? Is this something that you need at work or for a private project? I do not see this code applicable anywhere in neither core or client at the moment. What is the plan?

It is not for a specific work or private project. My intention was to add RFC 9209 support incrementally. I started with Core because the field syntax and model are generic HTTP semantics rather than client policy.

@arturobernalg Your plan is to provide it out of client? If so, this code should go to client. It can be moved to core once considered stable and there is an actual need for it.

@arturobernalg

Copy link
Copy Markdown
Member Author

Overall, what is your plan for this code? Is this something that you need at work or for a private project? I do not see this code applicable anywhere in neither core or client at the moment. What is the plan?

It is not for a specific work or private project. My intention was to add RFC 9209 support incrementally. I started with Core because the field syntax and model are generic HTTP semantics rather than client policy.

@arturobernalg Your plan is to provide it out of client? If so, this code should go to client. It can be moved to core once considered stable and there is an actual need for it.

@ok2c . That makes sense — I’ll move the implementation to Client first and keep it there until there is a demonstrated need to expose it from Core.

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.

2 participants