-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Feature: Add Context#Request#FullRequestPath
#1167
Comments
Hello @zheeeng, if you are using templates we already have the However, I am not big fan of depending on the |
Ok, I understand your pick. My situation is that my APIs is not for websites, it is for mobile clients and I want to provide downstream with some hyperlinks. In the website environment, the client can call hyperlink without domain and schema directly coz browser will add them, if the API and website are under the same domain, but mobile won't. Either client have to concatenate domain, schema, and the relative link comes from the response together, or the response comes from servers contains the full heuristic hyperlink without addtional concatenating. I personally prefer the later. And in the snippet, the |
context::Request::FullRequestPath
Context#Request#FullRequestPath
@kataras I found that Github API v3#link-header response user the full link address with schema and host, it is what I want to achieve as well. |
Yes but Iris can't know the full url of your site, you may run it under a proxy or under a root level domain or subdomain and you can do it by not providing Iris the internet domain, i.e you run iris by This is why I noted that I can't export a function like this, because users will missunderstand its usage and its limits. But why not make a simple template function or just a function which will return the scheme and your domain? The path of the request is easy to be resolved as shown on the previous comments, PORT also. Have you seen the |
It seems that the proxy is transparent, even if the user accesses the server through a proxy, the responded full path is a proxied path. It is also ok no matter what the root level domain or subdomain is, it is not bound fixedly. The example code runs at distributed production servers and QA and testing servers, the parsed path is as expected. |
Aa I see, you want it at request-time, yes... Sorry, yes we can do that, we already have ctx.Host and ctx.Subdomain and ctx.RequestPatg(parsed bool) or ctx.Path and also ctx.Request().IsTLS() as I remember, I will add this FullRequestURI() feature request. |
@zheeeng I added this for the next, upcoming func FullRequestURI(ctx iris.Context) string {
scheme := ctx.Request().URL.Scheme
if scheme == "" {
if ctx.Request().TLS != nil {
scheme = "https:"
} else {
scheme = "http:"
}
}
host := ctx.Host()
path := ctx.Path()
return scheme + "//" + host + path
} package main
import (
"github.com/kataras/iris"
)
func main() {
app := iris.New()
app.Get("/mypath", func(ctx iris.Context) {
fullpath := FullRequestURI()
ctx.Writef("Request URI is: %s\n", fullpath)
})
app.Run(iris.Addr(":8080"))
} |
As requested at: kataras#1167 and kataras#1170 Former-commit-id: 781c92f444b3e362011be886b32cf88f89998589
Here request having an API that gets the
FullRequestURI
andFullRequestPath
fromcontext::Request
for giving the client some hypermedia link information, e.g. the next and previous page link in pagination fields.I made something to achieve it by myself for reference:
The text was updated successfully, but these errors were encountered: