Skip to content

Conversation

chadlwilson
Copy link
Contributor

@chadlwilson chadlwilson commented Aug 30, 2025

Highly WIP/experimental right now as currently involves a rewrite/re-"port-from-rack" of the parameter parsing algorithm, and needs further discussion since this library diverges from Rack in some respects already, and we'll need to decide whether we will persist with these in v3 operation.

https://github.com/rack/rack/blob/main/UPGRADE-GUIDE.md

Will also summarise the open discussion points at some point.

Open questions/discussion point

  • "Invalid nested query parsing syntax" support needs review and discussion, especially the inconsistencies in the existing impl depending on
  • Need to vendor rack-session also? rackup? Or rely on Rails/frameworks to bring them in?
  • Check whether removing the HeaderHash wrapper for error app has any effect on Rack 2.2
  • Remove rewindable support on 3.x since it is no longer a requirement?
  • Check response header array logic is compatible
  • Investigate whether we supporting response hijacking at all before, and whether #call support is needed
  • Are the changes to remove optional environment keys worth it, or easier to just keep them?

@chadlwilson chadlwilson added this to the 1.3.0 milestone Aug 30, 2025
Copy link
Member

@kares kares left a comment

Choose a reason for hiding this comment

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

nice attempt to support both versions, seems maintainable...

@runtime = @rack_factory.getApplication.getRuntime
should_eval_as_not_nil "defined?(Rack.release)"
should_eval_as_eql_to "Rack.release.to_s[0, 3]", '2.2'
should_eval_as_eql_to "%w(2.2 3.1 3.2).include? Rack.release.to_s[0, 3]", true
Copy link
Member

Choose a reason for hiding this comment

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

IMHO isn't a good test this way, we should maybe duplicate these per each Rails/Rack version tested.

Copy link
Member

Choose a reason for hiding this comment

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

I see now that there's "rails80" => %w[rack22 rack31 rack32] so in that sense I guess this is fine...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah it's not good, but I couldn't think of a way to pass in the expected version cleanly without checking loaded gems which is kind of circular....

# emulating Rack::Utils.parse_nested_query behavior
raise ::Rack::Utils::ParamsTooDeepError if depth >= 32
Copy link
Member

@kares kares Sep 2, 2025

Choose a reason for hiding this comment

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

isn't the depth configurable in Rack itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems just a hard coded security thing :(

@chadlwilson chadlwilson linked an issue Sep 3, 2025 that may be closed by this pull request
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.

Rack 3.x support
2 participants