Skip to content

Fix response framing edge cases - #98

Merged
djc merged 8 commits into
djc:mainfrom
valkum:fix1
Oct 5, 2026
Merged

djc merged 8 commits into
djc:mainfrom
valkum:fix1

Conversation

@valkum

@valkum valkum commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

This fixes a couple of edge cases I found.
It is stacked on #84, so you can either close that one and merge this (I cherry-picked with correct attribution) or I will rebase once the other one is merged.

  • Limit the buffer size a response can allocate. The default is 1 MiB. This can be set using set_max_read_buf. We might want to find something more ergonomic, but I would like to land this sooner rather than later.
  • Reject a frame length that is shorter than what we already read.
  • Clear the in-flight state only after a successful reconnect to avoid handing out a response to the wrong command.
  • Correctly complete a frame that arrived in one read.
  • We now correctly decode the size when the size header arrives in two or more reads.
  • Properly escape the transaction ID.

This is a breaking change: it adds the Error::ResponseTooLarge variant.

I made sure the tests fail without the applied fixes.

@djc djc left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

LGTM modulo a few nits, please rebase on current main.

Comment thread src/connection.rs Outdated
Comment thread src/error.rs
Comment thread src/connection.rs Outdated
@djc

djc commented Oct 5, 2026

Copy link
Copy Markdown
Owner

Do you want/need a release after this or are you using it from git anyway?

valkum added 8 commits October 5, 2026 13:30
The registry sets the response size, and the client allocated with no
limit. A size above max_read_buf now causes an error.
The buffer could shrink below the read offset, which would cause a
panic.
A failed connect kept the old stream but cleared the in-flight requests,
so the next command could get the response of the earlier request.
The client polled again with a zero-length buffer, which could result
in an EOF or an infinite wait.

A frame that arrived in one read kept the zero padding of the 256-byte
read buffer. It is now truncated.
The 4-byte header could be split across reads. The length came only
from the last read. That gave a wrong length, or a panic when that read
had fewer than 4 bytes.
The clTRID went into the request XML without escaping. Markup in the ID
could add elements to the EPP command.
@valkum

valkum commented Oct 5, 2026

Copy link
Copy Markdown
Contributor Author

We do not need a release as long as some other PRs here are not merged. I hope I can come back to them soon to finish the work and get them into a state you are happy with.

Due to the nature of the issues fixed in this PR I think it would be valuable to cut a release, though.

@djc
djc merged commit b03a837 into djc:main Oct 5, 2026
7 checks passed
@djc

djc commented Oct 5, 2026

Copy link
Copy Markdown
Owner

Published 0.5.0.

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