-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse URI Query Parameters #67
Conversation
|
||
%w(verify fail_if_no_peer_cert cacertfile certfile keyfile).each do |ssl_option| | ||
if normalized_query_params[ssl_option] && uri.scheme == "amqp" | ||
raise ArgumentError.new("Only of use for the amqps scheme") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This message doesn't clarify what is "of use" (can be used). Please add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, what does sound the best?
'verify' TLS option is applicable only for 'amqps' schema
'verify' option should be used only within 'amqps' schema
TLS options are relevant only for 'amqps' schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"The option 'verify' can only be used in URIs that use amqps for schema". Arguably it should be a warning since non-TLS connections would simply ignore it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind to convert it to the warning, but an exception could attract attention to the possible misspelling of the schema. Maybe you already have a convention in this or other ruby-amqp
libraries, so it will be natural to keep consistent behavior across all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OMG, it was so fast. I feel like talk too much ^_^
Leave the exception or change to the warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did change the message in 50dbf6b but because I cannot push that to your repo, it won't show up here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I noticed when fetched upstream ^_^ That's OK. BTW, is it preferable to contribute from forked repo or straight to the initial repo? There is no CONTRIBUTION guide in amq-protocol
;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have the permissions to push to the mainline. I see no reason to not pull from and branch off of it. I don't really care as long as the PR is against the correct branch and is something I'd accept.
## Changes between 2.2.0 and 2.3.0 (Jan 8th, 2018) ### Support for Additional URI Query Parameters GitHub issue: [#67](ruby-amqp/amq-protocol#67), [#68](ruby-amqp/amq-protocol#68), [#69](ruby-amqp/amq-protocol#69). Contributed by Andrew Babichev.
PR for #66
So here is the
AMQ::URI.parse
method extension for query parameters. This is a prototype code that I'd like to polish after main ideas agreement:• Introduce
DEFAULTS
constant to keep them as some kind of declaration• Raise
ArgumentError
for ssl/tls parameters along withamqp
schema• Some concerns about
URI
andCGI
usage. I'm not so keen on this libraries to understand what should help us escape and parse properly. Could somebody give insight regarding this?@michaelklishin, do you like such nested structure of the contexts in the specs? I noticed you don't compose contexts and prefer to interpolate
"when ...
inside example description. If you find such approach more flexible and expressive, I'd happy to adjust existing specs inuri_parsing_spec.rb
file to the same look.