Make query parameters without = have nil values #2059
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
)" This reverts commit 5f90c33.
This reverts commit d25fedd.
This reverts commit 9f059d1.
This was Rack's historical behavior. While it doesn't match URL spec section 5.1.3.3, keeping the historical behavior avoids all of the complexity required to support the URL spec standard by default, but also support frameworks that want to be backwards compatible. This keeps as much of the specs added by the recently reverted commits that make sense.
|
I think what we've identified here is that the way I think we should consider those assumptions carefully and attempt to build something more robust going forward. Now we know a lot more about the different assumptions and ways we can address them, I think we should consider this for Rack 4. |
💯💯💯 |
ioquatix
added a commit
to ioquatix/rack
that referenced
this pull request
Mar 16, 2023
* Revert "Prefer to use `query_parser` itself as the cache key. (rack#2058)" This reverts commit 5f90c33. * Revert "Fix handling of cached values in `Rack::Request`. (rack#2054)" This reverts commit d25fedd. * Revert "Add `QueryParser#missing_value` for handling missing values + tests. (rack#2052)" This reverts commit 59d9ba9. * Revert "Split form/query parsing into two steps (rack#2038)" This reverts commit 9f059d1. * Make query parameters without = have nil values This was Rack's historical behavior. While it doesn't match URL spec section 5.1.3.3, keeping the historical behavior avoids all of the complexity required to support the URL spec standard by default, but also support frameworks that want to be backwards compatible. This keeps as much of the specs added by the recently reverted commits that make sense. # Conflicts: # lib/rack/multipart.rb # lib/rack/request.rb # test/spec_request.rb
ioquatix
added a commit
that referenced
this pull request
Mar 16, 2023
* Revert "Prefer to use `query_parser` itself as the cache key. (#2058)" This reverts commit 5f90c33. * Revert "Fix handling of cached values in `Rack::Request`. (#2054)" This reverts commit d25fedd. * Revert "Add `QueryParser#missing_value` for handling missing values + tests. (#2052)" This reverts commit 59d9ba9. * Revert "Split form/query parsing into two steps (#2038)" This reverts commit 9f059d1. * Make query parameters without = have nil values This was Rack's historical behavior. While it doesn't match URL spec section 5.1.3.3, keeping the historical behavior avoids all of the complexity required to support the URL spec standard by default, but also support frameworks that want to be backwards compatible. This keeps as much of the specs added by the recently reverted commits that make sense. # Conflicts: # lib/rack/multipart.rb # lib/rack/request.rb # test/spec_request.rb
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
May 15, 2023
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
May 15, 2023
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
May 16, 2023
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
Aug 7, 2023
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
geoffharcourt
pushed a commit
to commonlit/sinatra
that referenced
this pull request
Nov 6, 2023
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
Dec 23, 2023
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
Jan 2, 2024
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
dentarg
added a commit
to dentarg/sinatra
that referenced
this pull request
Jan 5, 2024
Rack v3.0.7 rolled back this change with rack/rack#2059 Other references: - rails/rails#47652 - rack/rack#2052 - rack/rack#2038
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was Rack's historical behavior. While it doesn't match
URL spec section 5.1.3.3, keeping the historical behavior avoids
all of the complexity required to support the URL spec standard
by default, but also support frameworks that want to be backwards
compatible.
This reverts the four recent commits that added a lot of additional
complexity just to get the backwards compatible behavior. While
I think the URL spec behavior is better, I think it's better to have
the backwards compatible behavior without the complexity than
the URL spec behavior with all of the complexity required to also
allow frameworks to get the backwards compatible behavior.
This keeps as much of the specs added by the recently reverted
commits that make sense.