URLs can be broken up into these components:
Sample URL: http://www.server.com:8080/path?query=string#fragment
protocol = http
host = www.server.com
port = 8080
path = /path
query = ?query=string
fragment = #fragment
Is there an established name for everything that comes after port (path, query, and fragment)? I was tempted to just call this "path" but that is not a good name as it does not include the query and fragment.
The IETF URI Spec defines the combination of these elements (path, query, and fragment) as a Relative Reference.
Perhaps "relative URL", as in "relative to Site Root"
The URL structure you are giving is containing the basic elements, and the fragment is usually coming before the query, the query in general is used when you are listing a part of data, so you need to access to it by this query, and parameters if needed.
Here a good review to list the steps for creating a good url.
there is no established name for everything together due to them all being different. Also you forgot the parameters part of the url. The parameters go in the query.
Related
Should a WebDAV server support query strings?
I have not found a clear statement about this in RFC 4918.
Background is as follows:
I have a WebDAV server where the path in the URL is mapped quasi 1:1 to the path to the resource in the file system. I.e. to get to the resource I need to know the path, something like this:
Variant 1:
http://<webdavserver>:<port>/folder1/subfolder1/anotherfolder/resource.txt
Now I have another client that doesn't know the path, but only two Ids (RepositoryId and DocumentId), but these also uniquely identify the resource. By searching for the two ids, the WebDAV server can also find the resource and return it.
Until now, this was solved in such a way that instead of the path in the URL, the two IDs were specified as a query string, i.e. something like this:
Variant 2:
http://<webdavserver>:<port>/?repoId=123&docId=456
Somehow this feels wrong ...
Well, actually the identifcation via the two ids is just an alternative representation to the path, isn't it? So something like this should work too:
Variant 3:
http://<webdavserver>:<port>/<repoId>/<docId>
http://<webdavserver>:<port>/123/456
This feels more "WebDAV-like" ...
I would only need to be able to distinguish on the server side which of the two URL representations is arriving there, path or ID.
Possibly via a header, something like
X-ResourcePath: Path | Id (Default would be Path)
What do you think?
Should I stay with variant 2, or rather switch to variant 3, or ...? (I have to reimplement it anyway, so "Do not change a running system" would not be a valid argument :-))
IMHO: it really doesn't matter. There's no prohibition to mix query params into WebDAV URI trees. You just need to make sure that the clients that you support will work with this.
(I would advise against moving identifying data into custom request header fields; this is what the URI is for).
When I implemented a WebDAV server I was primarily interested in supporting existing clients and I found that most of them did not support query strings in any way (namely Microsoft Office)
I ended up using the following format which seems to work for all clients:
protocol://server/id/title.extension
Backbone.js maintains routing information in a URL after the hash mark, e.g.:
http://localhost:3000#page/hardware/table/?action=details&actionTargetId=5&actionTargetName=10.3.177.185&actionTarget=host
Even though the routing information is in the format ?p1=v1&p2=v2&p3=v3, this portion is not technically part of the url query string since it comes after the hash mark.
My question is if I add an actual query string to our app's urls like this:
http://localhost:3000?newparam=newvalue#page/hardware/table/?action=details&actionTargetId=5&actionTargetName=10.3.177.185&actionTarget=host
is there any possibility of the "newparam" url parameter interfering with the backbone portion?
the problem is your not actually creating a legit query string. your mixing your route with your parameters.
your example is formatted as:
domain ? param # route ? other params
as soon as a questionmark appears in a url everything after it is interpreted as a query string. (in this case) even your route.
personally i suggest using the html5 pushstate.
Backbone.history.start({pushState: true})
this will give you clean(er) urls
http://localhost:3000/page/hardware/table/?newparam=newvalue&action=details&actionTargetId=5&actionTargetName=10.3.177.185&actionTarget=host
that will help your routes to not interfere with your parameters.
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence). However, is it a valid thing to do according to the HTTP specification? Say you were to POST to:
http://1.2.3.4/MyApplication/Books?bookCode=1234
... and submit some update like a change to the book name whose book code is 1234, you'd be wanting the processing code to take both the bookCode query string param into account, and the POSTed form params with the updated book information. Is this valid, and is it a good idea?
Is it valid according HTTP specifications ?
Yes.
Here is the general syntax of URL as defined in those specs
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
There is no additional constraints on the form of the http_URL. In particular, the http method (i.e. POST,GET,PUT,HEAD,...) used don't add any restriction on the http URL format.
When using the GET method : the server can consider that the request body is empty.
When using the POST method : the server must handle the request body.
Is it a good idea ?
It depends what you need to do. I suggest you this link explaining the ideas behind GET and POST.
I can think that in some situation it can be handy to always have some parameters like the user language in the query part of the url.
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence).
Any competent framework should support this.
Is this valid
Yes. The POST method in HTTP does not impose any restrictions on the URI used.
is it a good idea?
Obviously not, if the framework you are going to use is still clue-challenged. Otherwise, it depends on what you want to accomplish. The major use case (redirection of a data subset to a new POST target) has been irretrievably broken by browser implementations (all mechanically following the broken lead of Mosaic/Netscape), so the considerations here are mostly theoretical.
I'm using URLRewritingNet 2.0. How do I rewrite URL's in ASP.NET?
Here is the request:
Input: www.sampleweb.com/param1/value1/param2/value2/default.aspx
Output: www.sampleweb.com/default.aspx?param1=value1¶m2=value2
It must work dynamically like this param1/value1/param2/value2/ ... /paramN/valueN
That is not a good way to pass key/value pairs.
You should assume the key based on the values position. That makes life a lot easier. HttpContext.RewritePath (with its variations) is how you go about transforming the url.
So...basically you can't do this in the "rewrite" node in your web.config file using ASP.Net's URL Rewriter.
But you could do it elsewhere in your code (an HTTP Module, or Begin Request, or whatever). To transform you URL's you could do something like this:
string strRegex= #"/([^/]*)/([^/]*)";
RegexOptions myRegexOptions = RegexOptions.None;
Regex myRegex = new Regex(strRegex, myRegexOptions);
string strTargetString = #"/param1/value1/param2/value2/param3/value3/param4/value4";
string strReplace = #"$1=$2&";
If you combine that with matching the filename (here's the RE):
(.*)/([^/]*\..*)$
And then re-composing the complete URL--then you could Server.Execute or whatever (if on your own server) or otherwise proxy over to where you want this processed. Yup, it's a little ugly, but if you don't have control of the shape of the request coming at you, this is a way to transform it.
Part of my application maps resources stored in a number of locations onto web URLs like this:
http://servername/files/path/to/my/resource/
The resources location is modelled after file paths and as a result there can be an unlimited level of nesting. Is it possible to construct an MVC route that matches this so that I get the path in its entirety passed into my controller? Either as a single string or possibly as an params style array of strings.
I guess this requires a match on the files keyword, followed by some sort of wildcard. Though I have no idea if MVC supports this.
A route like
"Files/{*path}"
will get the path as a single string. The * designates it as a wildcard mapping and it will consume the whole URL after "Files/".
For more information on ASP.NET's Routing feature, please see MSDN:
http://msdn.microsoft.com/en-us/library/cc668201.aspx
And for the "catch-all" parameters you want to use, see the section under "Handling a Variable Number of Segments".