I'm currently trying to use Tuckey and Tomcat to rewrite URLs.
At the moment I'm trying to translate
myapp.com/track/2340ddkef?dkfkeif&3434
to
myapp.com?req=track&id=2340ddkef?dkfkeif&3434
But after the first ? or & the parameter is cut off and only
myapp.com?req=track&id=2340ddkef
is send to the servlet. How can I change that behavior? Is that even possible with Tuckey or do I need to apply some filter which to ensure the characters are not lost?
Embedding ? and & in URLs like that really isn't valid. You should URL encode those strings. For example, in Java, use
URLEncoder.encode(id, "UTF-8")
Related
I'm using Thymeleaf.
I've a link build with th:ref
<a th:href="#{http://www.pippo.com/a=3&y=4&u=10}">
That is converted into
http://www.pippo.com/a=3&y=4&u=10
So & is converted into &
How can i convert & to & ?
Thanks
th:href is meant to be used for relative urls or urls that come (partly) from a model variable.
This Means that in your case with a static url you should be using regular href making
A secondary issue might be using & as part of the url, this character is normally reserved for url paramaters and might not behave like you expect it to if you use it as an url part.
Looking at your url I would expect it to look like http://www.pippo.com?a=3&y=4&u=10 in thymeleaf this could be #{http://www.pippo.com(a=3,y=4,u=10)}
I want to have a parameter with slashes in the router in gin.
From what I gathered I can do this by adding a wildcard to the URL. For example: /api/v0/files/*addr
But this approach doesn't work if I want to have the addr in the middle of the URL like /api/v0/*addr/files, and it returns this error:
catch-all routes are only allowed at the end of the path.
I was wondering whether there is another way of having it?
Seems that is a limitation of the Gin framework, as seen # https://github.com/gin-gonic/gin/blob/master/tree.go#L322
You could always invert the order and do a rewrite using a proxy and a regexp (i.e. /api/v0/*addr/files to /api/v0/files/*addr) or only accept methods ending with /files inside your handling function, but I'm afraid that is a hardcoded limitation of the Gin framework.
I have a url, "localhost/test/http://myimage.com/" (I'm passing myimage.com, because it's hosted on another site and I'm accessing it via an api) my question is how do I go about encoding the image portion of the URL? I thought about doing a gsub on the '.' and '/' and then gsubing them back, but I'm wondering if there's an easier way. Thanks for your help.
You could use URI::encode_www_form_component(str) and URI::decode_www_form_component
Check: http://www.ruby-doc.org/stdlib-1.9.3/libdoc/uri/rdoc/URI.html
You can use the uri library to escape and unescape a url
require 'uri'
escaped = URI.escape(data, Regexp.new("[^#{URI::PATTERN::UNRESERVED}]"))
and you can get the data back with
original = URI.unescape(escaped)
I made a Spring REST application where you can perform CRUD operations based on HTTP methods of POST, PUT, GET, DELETE. I have the typical URI template of
http://host/root/{id}/{name}/{address} and etc.
We have a client who is accessing this REST service. Apparently they are sending parameters for multi-word name and address in the following form:
http://host/root/11/John+Smith/10+Las+Vegas+USA
They are using the HTML encoding scheme based on application/x-www-form-urlencoded type. According to the article in Wikipedia
The application/x-www-form-urlencoded
type
The encoding used by default is based
on a very early version of the general
URI percent-encoding rules, with a
number of modifications such as
newline normalization and replacing
spaces with "+" instead of "%20". -
http://en.wikipedia.org/wiki/Percent-encoding
However it appears the standard URL encoding scheme is to use %20 in replacing spaces in URI templates. Which one is correct?
My Spring REST automatically converts %20 to spaces. It's interpreted correctly. I'm using Spring 3.0.4. When + is met by my REST service, it's accepted as is. Of course when I put validation to exclude +, it is indeed excluded as expected.
Am I within standards or are there such double standards? Or is the client using an ancient scheme?
The point is that application/x-www-form-urlencoded can be used only in request parameters, whereas percent encoding is also supported in a path.
So,
http://host/root/11/?name=John+Smith&address=10+Las+Vegas+USA
is fine and will be properly decoded by Spring MVC, but
http://host/root/11/John+Smith/10+Las+Vegas+USA
is wrong and Spring MVC doesn't decode it, because the following form should be used instead:
http://host/root/11/John%20Smith/10%20Las%20Vegas%20USA
I have read a lot about URL rewriting but I still don't get it.
I understand that a URL like
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=19
can be replaced with a friendlier one like
http://www.example.com/Blog/2006/12/19/
and the server code can remain unchanged because there is some filter which transforms the new URL and sends it to the old, but does it replace the URLs in the HTML of the response too?
If the server code remains unchanged then it is possible that in my returned HTML code I have links like:
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=20
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=21
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=22
This defeats the purpose of having the nice URLs if in my page I still have the old ones.
Does URL rewriting (with a filter or something) also replace this content in the HTML?
Put another way... do the rewrite rules apply for the incoming request as well as the HTML content of the response?
Thank you!
The URL rewriter simply takes the incoming URL and if it matches a certain pattern it converts it to a URL that the server understands (assuming your rewrite rules are correct).
It does mean that a specific resource can be accessed multiple ways, but this does not "defeat the point", as the point is to have nice looking URLs, which you still do.
They do not rewrite the outgoing content, only the incoming URL.