Say you have a mapserver-url like this: http://host/cgi-bin/mapserv?MAP=/path/to/mapfile.map&
Is a WMS specified in this way conform to the OGC WMS-specification? Some say the map-parameter is a vendor-specific parameter, but you also could see it as part of the URL-prefix for this service (ending with ? or & as specified, it's an & in this case). What do you think, is that compatible to the specification or not?
The OGC WMS 1.1.1 (Section 6.2.2)and 1.3.0 (Section 6.3.3) specifications are fairly clear regarding this topic:
An Online Resource URL intended for
HTTP GET requests is in fact only a
URL prefix to which additional
parameters are appended in order to
construct a valid Operation request. A
URL prefix is defined in accordance
with IETF RFC 2396 as a string
including, in order, the scheme
(“http” or “https”), Internet Protocol
hostname or numeric address, optional
port number, path, mandatory question
mark “?”, and optional string
comprising one or more server-specific
parameters ending in an ampersand
“&”.
As long as the online resource URL finishes with an "&", it should adhere to the WMS specification
Related
I'm using the Actions on Google OAUTH authorization flow. In the authorization URL, Google passes along a very long "state" parameter (500+ char) in the URL, yielding an error on the OAauth client/server (Bunq to be precise).
I've seen more cases where this is an issue, also including Amazon Skills.
If I manually shorten the length of the 'state' parameter, the error disappears. But since Google is using the 'state' parameter as a "bookmarking value", they do not allow for any alterations. There seems to be no way to resolve this issue on my side.
Here is an example of the Authorization URL that is generated by Actions on Google:
https://oauth.bunq.com/auth?redirect_uri=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2F[MY PROJECT NUMBER]&client_id=[CLIENT ID]&response_type=code&state=[567 CHARACTERS]
Is there a way to shorten the state parameter, or to resolve this issue otherwise?
While there is no specified limit on the characters forming a URL specified by the Network Working Group in RFC 2616, the defacto convention used by many internet systems and browsers is up to 2k characters. You should check with the internal codebase as well if there is any limit on the number of characters that can be included in a query string.
I am currently integrating Amazon CloudSearch with a front end application.
Due a known CORS issue, I am forced to use API Gateway too.
The issue occurs that, the front end CloudSearch library send the url with encode parameters. Those parameters are received by API Gateway, decoded and forwared to CloudSearch.
Is there a way to configure CloudSearch to accept a decoded slash? Is there a way to make API Gateway to not decode the parameter during forward?
I'm unable to determine the exact issue you are having without a specific example. I'm assuming that you're passing a query string parameter into API Gateway and then passing this parameter onto CloudSearch as another query string parameter.
Here is the expected behavior: When you pass a query string parameter in to API Gateway, it will first url decode the parameter value. This will decode any characters which were percent encoded, regardless of whether or not the original character needed to be percent encoded in order to conform to the URL RFC. If the parameter is being passed as a query string parameter to an integration endpoint, then API Gateway will URL encode the parameter value by percent encoding only the characters which are not valid characters to appear in a query string value.
Based on this behavior, it's not clear how a decoded slash is being passed to CloudFront. If you can provide a specific example, I can investigate further.
According to the URL syntax there are supposed to be slashes after the colon following the protocol. An email link, e.g.
mailto:bla#shoe.com
, however, does not contain these slashes.
Can these addresses be considered valid URLs ?
The URI standard is STD 66 which currently maps to RFC 3986.
The double slash you know from some URIs (e.g., from HTTP URIs like http://example.com/) precedes the authority component, but this authority component is not required by the generic URI syntax (only scheme and path are).
So, the mailto URI scheme is not using the authority component, and therefore there is no // after the scheme component.
Should parameters for POST requests (elements of the resource being created) be allowed to be added to the URL as well as in the body?
For example, let say I have a POST to create a new user at
/user
With the full set of parameters name, email, etc... in the body of the request.
However, I've seen many API's would accept the values in either the body or URL parameters like this:
/user?name=foo&email=foo#bar.com
Is there any reason this second option, allowing the parameters in the URL is bad practice? Does it violate any component of REST?
The intent of a query parameter is to help identify the target resource for a request. The body of a POST should be used to specify instructions to the server.
The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any).
-- RFC 3986 Section 3.4
The hierarchical path component and optional query component serve
as an identifier for a potential target resource within that origin
server's name space.
-- RFC 7230 Section 2.7.1
The Udacity Web Development course, be Steve Huffman (the man behind Reddit), recommends only using POST requests to update server side data. Steve highlights why using GET parameters to do so can be problematic.
I am building a RESTful API for retrieving and storing comments in threads.
A comment thread is identified by an arbitrary URI -- usually this is the URL of the web page where the comment thread is related to. This design is very similar to what Disqus uses with their system.
This way, on every web page, querying the related comment thread doesn't require storing any additional data at the client -- all that is needed is the canonical URL to the page in question.
My current implementation attempts to make an URI work as a resource by encoding the URI as a string as follows:
/comments/https%3A%2F%2Fexample.org%2Ffoo%2F2345%3Ffoo%3Dbar%26baz%3Dxyz
However, before dispatching it to my application, the request URI always gets decoded by my server to
/comments/https://example.org/foo/2345?foo=bar&baz=xyz
This isn't working because the decoded resource name now has path delimiters and a query string in it causing routing in my API to get confused (my routing configuration assumes the request path contains /comments/ followed by a string).
I could double-encode them or using some other encoding scheme than URI encode, but then that would add complexity to the clients, which I'm trying to avoid.
I have two specific questions:
Is my URI design something I should continue working with or is there a better (best?) practice for doing what I'm trying to do?
I'm serving API requests with a Go process implemented using Martini 'microframework'. Is there something Go or Martini specific that I should do to make the URI-encoded resource names to stay encoded?
Perhaps a way to hint to the routing subsystem that the resource name is not just a string but a URL-encoded string?
I don't know about your url scheme for your application, but single % encoded values are valid in a url in place of the chars they represent, and should be decoded by the server, what you are seeing is what I would expect. If you need to pass url reserved characters as a value and not have them decoded as part of the url, you will need to double % encode them. It's a fairly common practice, the complexity added to the client & server will not be that much, and a short comment will do rightly.
In short, If you need to pass url chars, double % encode them, it's fine.