-
Notifications
You must be signed in to change notification settings - Fork 23
Parse/print tweaks #32
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
Conversation
|
I think that similar change should be introduced for |
|
@paluh yeah, I was looking at the |
|
Wow, the parsers are really messed up right now, no wonder those current test cases fail 😄 I have some ideas now... sorry for leaving that other thread hanging in which we discussed this stuff @paluh, but I do have some ideas about some fixes now at least! |
|
https://tools.ietf.org/html/rfc3986#section-3.2 In case of relative ref I think that for example So yes |
|
ABNF and regex from the spec seems to be consistent with this description...
No problem - I know that you are busy ;-) |
|
@paluh thanks for those pointers, now the authority stuff has been untangled the |
kritzcreek
left a comment
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.
Looks good!
|
|
||
| parser ∷ Parser AbsoluteURI | ||
| parser = AbsoluteURI | ||
| <$> (optionMaybe Scheme.parser <* string ":") |
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.
Don't need these parens
I would consider the current behaviour to be a bug. Certainly for the query anyway since one way included
?and the other did not - the fragment did not require it in either, but that it was different seemed weird so I thought I'd make it consistent in that regard also. Made the code a bit cleaner as a bonus, reduced some repetition of#printing/parsing in each URI variety.