I figured this was going to be a straight forward exercise via a ResourceRequestHandler and overriding the OnResourceResponse.
But the implementation throws NotSupportedException: IResponse is read-only and cannot be modified. Check IResponse.IsReadOnly to guard against this exception, if I try to manipulate the Headers or even if I try to call SetHeaderByName on the IResponse
I found this Cef issue, so I figure it is a Cef limitation. Is this correct ?
I also had a look at if it might be possible to implement a custom IResourceHandler and manipulate the response headers via GetResponseHeadersmethod, but any discussion of this Interface online seems to refer around handling requests, not responses.
Can it be done with an IResourceHandler ? Are there some examples ?
Related
I'm implementing the logic for a RESTful web server which supports searching with a SolR like syntax. Here are some common valid requests:
"https://www.somewhere.com/fooResource/123"
"https://www.somewhere.com/fooResource/456"
"https://www.somewhere.com/fooResource?q=title:hi"
"https://www.somewhere.com/fooResource?q=title:hello&sort=foo"
My question is very generic; what should I do if I receive a request like this?
"https://www.somewhere.com/fooResource?q=title:hi&something=foo"
I received a query parameter "something" which has no meaning to me, and our search engine will ignore it. Should I
return a 4xx status code immediately
ignore it and return a 200 with results
either my be "right" depending on my use case
Many web pages just ignore stuff that they aren't expecting.
Usually the URL and parameters are a result of clicking something or running some code on a browser or web service client. These would seldom submit anything unexpected.
If there is some reason you expect someone to be fooling with your web site and submitting requests that are "hackish" in some fashion, you might want to lock them out by recognizing illegal parameters and returning some error. 4xx would be reasonable for REST service.
Read the HTTP status definitions. I would practice not returning anything with bad info. The definition of 400 is The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. and seems appropriate here, but your use case may deem otherwise.
If you IGNORE you are not giving the client any information. They may never know something is wrong.
I use ASIHTTPRequest framework in my iPhone application to manage the HTTP communication. I followed their examples given in the project home page to send asynchronous requests. There we have to implement two callbacks, one for requestFinish and other for requestFailed.
However, 60% of the time requests sent by the iPhone ends up in the "requestFinish" callback method and gives a valid HTTP status code. But sometimes it goes to "requestFailed" callback and the status code become '0' which is confusing.
My investigations revealed that the internet connection is ok, and I am sending the request to the correct URL, however no log messages found in server log.
So why does the request gets dropped in the middle so randomly? Has anyone came across with this type of issue. Will be very helpful.
Thanks
Are you looking at the status code of the ASIHTTPRequest object? That code is simply an HTTP response code - if you didn't get a response, then that should be zero.
Instead, you want to look at the NSError object that the delegate failure callback gives you.
I would use something like:
NSLog(#"%#",[error localizedErrorDescription]);
To print out to the log what the error is. Of course, "error" is the name of the variable in the method signature - you should double-check that, I think that's what the default is.
In [ASHTTPRequest initialize], I changed
[sharedQueue setMaxConcurrentOperationCount:4]
to
[sharedQueue setMaxConcurrentOperationCount:10]
This work for me, but I don't know why.
MORE:
I found this.
As well as what phooze suggested, there is logging in ASIHTTPRequestConfig.h that you can enable, that may provide a clue as to what is happening.
I am adding headers to a page as follows:
Page.Response.AddHeader("foo", "bar");
Depending upon previous processing, sometimes this fails with "Server cannot append header after HTTP headers have been sent." I am dealing with this by enclosing Page.Response.AddHeader("foo", "bar"); within a try-catch construct. However, to keep things cleaner and avoid generating an exception is there any way to detect that the headers have already been sent? (btw if I try evaluating Page.Response.Headers then I get the following error: "This operation requires IIS integrated pipeline mode")
Thanks
As of .NET 4.5.2, you can do this using the now-public HeadersWritten property of HttpResponse (see the msdn docs):
if (HttpContext.Current.Response.HeadersWritten) { ... }
You can use an HttpModule to register for the PreSendRequestHeaders event. When it gets called, write a value to HttpContext.Current.Items indicating that the headers are being sent – and then everywhere else in your code you check the value in HttpContext.Current.Items to see if its been sent yet.
UPDATE: the HeadersWritten property is now available on the HttpResponse object.
Unfortunately, whilst the HttpResponse object has a property called HeadersWritten, and a backing field called _headersWritten, neither of these are accessible from outside of the System.Web assembly - unless you use Reflection. I'm not clear what you think you'll be able to obtain from the Headers collection, it may or may not exist, independently of whether the headers have been sent yet.
If you want to use Reflection, it may have it's own performance penalties, and it will require your application to run in full trust.
All of the publicly accessible methods on HttpResponse that involve the _headersWritten field seem to use it to throw an exception.
Trying setting buffer to false:
http://msdn.microsoft.com/en-us/library/950xf363.aspx
This will alleviate your first problem but your perfromance and user experience can suffer.
Also "This operation requires IIS integrated pipeline mode" is related to non-IIS 7 server processing that line of code. You can find more info on it here:
http://forums.asp.net/p/1253457/2323117.aspx
I am developing a RESTful framework and am deciding how to handle an unsupported verb being called against a resource. For example, someone trying to PUT to a read-only resource.
My initial thought was a 404 error, but the error is not that the resource cannot be found, it exists, just the user is trying to use the resource incorrectly. Is there a more appropriate error code? What is the most common way in which this situation is handled?
Is it that you simply don't support a certain verb ie DELETE? In that case I'd use the following HTTP response code if someone uses a verb you don't support.
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource;[2] for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource. [source]
I don't think you would receive a request to your app at all if the incorrect verb were used (but that probably depends on which specific technologies you're using on the server side).
To be more helpful to potentially confused client connection attempts I suppose you could create a stub endpoint/action for each commonly incorrect verb, method combinations and then send back a friendly "use {verbname} instead for this request" text response, but I'd personally just invest a bit of time in better developer documentation : )
You could also seamlessly redirect to the correct action in those cases...
Is there any way to determine if a POST endpoint exists without actually sending a POST request?
For GET endpoints, it's not problem to check for 404s, but I'd like to check POST endpoints without triggering whatever action resides on the remote url.
Sending an OPTIONS request may work
It may not be implemented widely but the standard way to do this is via the OPTIONS verb.
WARNING: This should be idempotent but a non-compliant server may do very bad things
OPTIONS
Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
More information here
This is not possible by definition.
The URL that you're posting to could be run by anything, and there is no requirement that the server behave consistently.
The best you could do is to send a GET and see what happens; however, this will result in both false positives and false negatives.
You could send a HEAD request, if the server you are calling support it - the response will typically be way smaller than a GET.
Does endpoint = script? It was a little confusing.
I would first point out, why would you be POSTing somewhere if it doesn't exist? It seems a little silly?
Anyway, if there is really some element of uncertainty with your POST URL, you can use cURL, then set the header option in the cURL response. I would suggest that if you do this that you save all validated POSTs if its likely that the POST url would be used again.
You can send your entire POST at the same time as doing the CURL then check to see if its errored out.
I think you probably answered this question yourself in your tags of your question with cURL.