From https://en.wikipedia.org/wiki/Query_string
A web server can handle a Hypertext Transfer Protocol request either
by reading a file from its file system based on the URL path or by
handling the request using logic that is specific to the type of
resource. In cases where special logic is invoked, the query string
will be available to that logic for use in its processing, along with
the path component of the URL.
What does the quote mean by the two methods by which a web server can handle a HTTP request
"by reading a file from its file system based on the URL path"
"by handling the request using logic that is specific to the type of resource"?
Can you give specific examples to explain the two methods?
Is the query string used in both method?
Thanks.
by reading a file from its file system based on the URL path
^ The web site uses a generic mapping mechanism to convert a URL path to a local filesystem path, and then returns the file located at that path. This is common with static files like .css.
by handling the request using logic that is specific to the type of resource"
^ The web site turns control over to a web application, which contains code written by a developer. The code reads the query string and decides what to do. The logic for deciding what to do is completely customizable, and there does not need to be a static file in the local filesystem that matches the URL.
Related
we would like to know if it is possible to send parameters to Webdav server (for example as query string path: http://server:8080/WebDavItHit/Notes.txt?param=value...") using IT Hit WebDAV Server Library for Java + JS Client.
We are looking forward to validate individual users using other application, and sending some parameters could be really useful.
We appreciate any way or alternative for doing this with your library.
Some WebDAV clients, such as MS Office will truncate query string when saving a document. So to pass parameters, you will typically do this in file path, for example:
https://server/[SessionID1234567890]/path/file.ext
I'm working on a direct-to-S3 upload service that operates in two parts described below. This service would not be used by browsers, but would be a RESTful API used by other software clients.
Make a request to an endpoint which certifies and validates the upload, returning an upload URL if all's well.
Make a PUT request to the URL returned from #1 to actually do the upload to S3.
How should the server structure the response for the first endpoint?
The first option I am considering would be to use GET and return a status code 302 with a Content-Location header containing the URL to upload to. However, the intent behind the redirect descriptions in the spec seems to be focussed on redirecting after a form submission.
The other option I'm considering is to use POST for the first endpoint and returning a Location header with the URL, as described here:
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header. RFC 2616 #9.5
Please advise on what other people have used in such circumstances?
I think it mainly depends on whether your API itself will have a resource referencing the uploaded file or not. The only one with knowledge of the uploaded file is the S3 itself or your API has something referencing it?
If the first case where only S3 knows about it, then it's OK to use the GET if it acts merely as a generator for the upload parameters, including the URI.
If the second case, then it shouldn't be a GET, since you're changing something on your side. Yes, you should make a POST, but the Location header should be used to return the URI for the created resource that references the uploaded file. That resource may have the upload URI and it could act like a state-machine, tracking if the file is uploaded or not. To avoid the need for clients to GET that resource before being able to upload, you may return the upload URI in the Link header, with a rel reflecting that purpose.
gwan/csp/strangesubfolder/inc.c can be visited via http://domainName.com/strangesubfolder/?inc
I feel this servlet mapping strange but that suits my need. I can't find the mapping description in the gwan user's manual.
Please correct me if I am wrong and confirm if it is the expected behavior.
Yes it is a standard feature.
The '?' tells G-WAN that it is a servlet. If there's no '?' it will look for the file in WWW folder.
Update:
Now I understand your confusion.
Since version release 3.3.27 this has been changed so users can easily make restful URL's
G-WAN timeline
Read the update for March 27 2012.
Now you need to place the '?' before the actual servlet name. By doing this G-WAN can efficiently rewrite '/' to '&' so you can use restful URL's like these without writing any code.
//Old way
http://domain/?user/profile&user1
http://domain/?blog/archive&2012&march
//New way (more restful no '&')
http://domain/user/?profile/user1
http://domain/blog/?archive/2012/march
Yes, as Richard rightly (and promptly, thanks Richard!) explained it, this is the expected behavior.
The directory /gwan/.../csp/script.c is used to store servlets that must be run while /gwan/.../www/script.c is used to store files intended to be served as an HTTP resource.
The corresponding URLs are GET /?script.c and GET /script.c.
Any sub-directory used in the /csp or /www folders is reflected accordingly in the HTTP request: GET /folder/?script.c for dynamic contents and GET /folder/script.c for static contents.
The choice of moving the '?' query character (which can be replaced by other characters) from the old GET /csp?/folder/script.c form to the new GET /folder/?script.c form was motivated by the need to:
distinguish servlet names from folder names (requests can lack the servlet extension for the defined 'default' programming language, which is C if nothing is defined)
allow any number of sub-directories in HTTP requests
allow any number of query arguments in HTTP queries
distinguish between folders and query arguments in HTTP requests
make it possible to have RESTFUL requests in all the above cases.
It took us a while to find the proper mix of features with the minimal verbosity but experience has shown that this works well.
Here is an example of a RESTFUL query having both a sub-folder and query arguments:
GET /folder/?script/arg1/value1/arg2/value2/arg3/value3
By default, this is a C script, unless another language (among the 15 available for scripting) has been defined as the 'default' language.
Note that the 50+ script examples provided in the download archive illustrate this scheme which is also presented on the developers page.
I'm using ASP.NET with MVC 2 and have trouble translating a local file url to a server address. It would seem like a fairly simple and common task, but google searches gives me no good answers. (Perhaps i suck at searching)
I have a controller that takes a file from a html form in a view and saves it to disk. I need to return the real url of this file back to the View. Whatever method i use, I always get a string with the local path of the file instead of the http path.
I suspect the url might get translated to http address once the project has been deployed, but I really need the server address when debugging without having to hardcode anything.
Consider the following example in some controller method:
string url = Url.RequestContext.HttpContext.Server.MapPath("~/Content/Files/" + Path.GetFileName(file.FileName));
// outputs: "C:\\Users\\xxx\\Documents\\Visual Studio 2010\\Projects\\[ProjectName]\\Content\\Files\\file.png"
// whereas i'd like something like "http://localhost/Content/Files/file.png" instead
any ideas?
It depends on where you are storing this file. If you are storing it in a directory which is outside of the virtual directory root you won't be able to access it. If the file is inside a folder which is accessible over HTTP you could simply use the Content method:
string url = Url.Content("~/Content/Files/foo.txt");
This is really a couple of questions about preventing unauthorized attempts to access a specific file type. Here go the questions:
How do I prevent users from directly requesting a type of file? Do I write an HTTP handler?
After preventing a direct download, can my app still explicitly serve that file type? How?
The way to do this is to:
Put all your tif files in a non publicly accessible location
Create an IHttpHandler to serve these tif files based on authentication (or whatever limitation you choose).
(Optional) Set up a rewrite rule so that all tif requests go through your IHttpHandler. This creates nice URL's again.