8000 Make Uri parser more restrictive · Issue #113 · pepegar/hammock · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Make Uri parser more restrictive #113

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.

Sign up for GitHub

By clicking “Sign up for GitHub& 8000 rdquo;, 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

Jump to bottom
Open
asoltysik opened this issue Jul 4, 2018 · 4 comments
Open

Make Uri parser more restrictive #113

asoltysik opened this issue Jul 4, 2018 · 4 comments

Comments

@asoltysik
Copy link
asoltysik commented Jul 4, 2018 •
edited
Loading

Currently it allows for some invalid URIs, which lead to runtime errors when passed to Apache HTTP (thrown by java.net.URI) or AsyncHttpClient.

Examples of invalid URIs which pass hammock.Uri.fromString parser:

  • ::
  • ^&%$#@!
  • http://^&%$#@!/foo
  • empty string and/or whitespace

A couple of ideas for how to solve this:

I'd be happy to contribute once you decide on direction.
@miciek
Copy link
Collaborator
miciek commented Jul 20, 2018

@asoltysik Thanks! I think second option would be the best. I haven't used at scala-uri but it looks like it's way better than java.net.URI.

@asoltysik
Copy link
Author

Looking at scala-uri it uses parboiled, which is a java library with scala wrapper. IIRC that makes it not an option as hammock is cross-published to ScalaJS.

@pepegar
Copy link
Owner
pepegar commented Jul 30, 2018

Yeah, the idea behind creating our own was to have something that worked for both scalaJS & JVM (and potentially scala native)

@miciek
Copy link
Collaborator
miciek commented Aug 13, 2018

OK, @asoltysik I think that the only way forward then is to improve existing parser :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pepegar @miciek @asoltysik
0