I am implementing a simple rest service with the 4 http methods get,post, put and delete using sitebricks. trying to send a delete request to the defined service with a WebClient I get a 405 response. Does anyone knows why would I get such response ?
10:22:24.840 [5907955#qtp-6711891-2 - /r/clients/123] DEBUG org.mortbay.log - RESPONSE /r/clients/123 405
This is how I use web client
WebClient client = web().clientOf(delete(123)).transports(String.class).over(Json.class);
client.delete();
here is my delete method
#Delete
#At("/:id")
public Reply delete(#Named("id") String id) {
clientsRepository.delete(id);
return Reply.saying().ok();
}
I am using Jetty Server.
Response code 405 means that something is configured to not allow the use of the http DELETE method.
I can't speak for sitebricks itself, but servlet spec allows you to disable specific methods.
The web.xml of your webapp or the ${jetty.home}/etc/webdefault.xml, as either could be configured to disallow the use of specific HTTP methods (like TRACE, PUT, DELETE).
Check those files for <security-constraints> that might have <http-method> declarations for DELETE.
Also note that any code can trigger the 405 response itself.
Since you are seeing this in Sitebricks, possibly a <filter> in your web.xml is preventing it.
Are you constructing the request URI properly? Sitebricks returns 405 if there is no handler method. This test case verifies that #Delete does indeed work properly:
https://github.com/dhanji/sitebricks/blob/master/sitebricks-acceptance-tests/src/main/java/com/google/sitebricks/example/RestfulWebServiceWithSubpaths2.java
Also as joakime says, do check if any other filters or handlers are firing outside Sitebricks.
Related
Let's say I've got route /posts. It only implements GET HTTP method.
If someone tries to access it with different, existing method (POST, PUT, etc.) I return 405.
What should I return in case someone tries using some unsupported, nonexistent method like MYCUSTOMMETHOD or SFASFS? 405 method not allowed or rather 501 not implemented or maybe even 400 bad request (seems to be default behaviour in node express) , as such methods are not in HTTP specs?
Is there any spring annotation available for capturing http method.
essentially I have a legacy controller where a single method is handling POST, PUT, PATCH.
Now I need to add a funcitonality which is applicable only for POST. Thus i want to throw an error if consumer sends request with method other than POST.
Thus I want to capture the request method.
I know I can get it easily using httpservletrequest.getMethod() but I want to use spring's annotation to capture it. This will be help me keep my code clean.
Query: Does spring support any annotation through which I can capture http the request method.
Thanks,
You have:
#GetMapping
#PostMapping
#PutMapping
(...)
and others
When you put for example #GetMapping and try to request another method you will automatically receive HTTP error 405 - method not allowed.
Available since version 4.3.
Example:
We provide a URL http://.../foo/download.csv
web client (MS office) opens above URL and tries to access (for reasons I really don't know) http://.../foo/ with an http OPTIONS request.
Up to now or app returns 404 since the above URL does not exist (even for GET requests).
I think All OPTIONS requests should get a 405. It should not matter if the URL would be accessible via GET or POST.
Does this match the http spec?
Here is my explanation why I think 405 fits better: If there is an OPTIONS request, I don't want to look at the path. I don't care what the path looks like, there should always be the same answer: Not allowed.
Up to now it depends: if there is a GET-view registered, then we return 405. Otherwise a 404 gets returned.
Update: 404 vs 405
HTTP-Spec 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6
It's not really clear why you want it to return a 405, to be honest. It'll never get as far as checking the method, because the 404 handler will be invoked first - there's no view logic for it to get, that's what the 404 is. This is the default, and correct, behaviour.
I suspect, if you don't want to write custom middleware for it, and you insist on implementing it, that overriding the 404 handler would be the way forward - if a 404 Handler is invoked, check the method and return that accordingly - this is messy though, and the custom middleware would be more pythonic.
def handler404(request):
if request.method == 'OPTION':
#return your custom 405 response
else:
#go on and do your regular 404.
I am using webMethods from the SAG and it seems if the service
pub.client.http
throws an exception on status code 401 "Unauthorized".
This leads me to the problem that I cannot handle the status code because nothing is written to the pipeline.
getLastError
does contain the string "Unauthorized" but not the status code.
Except that I do not want to start parsing exception messages...
Any ideas?
The output parameter header from the pub.client.http call should contain the information you’re after:
header Document Conditional. HTTP response headers.
Key Description
lines Document Fields in the response header, where key names represent
field names and values represent field values.
status String HTTP status code of the response.
statusMessage String HTTP status message of the response.
See the webMethods Integration Server Built-In Services Reference page 122 for more details.
Asked a SAG senior consultant.
This is the normal behavior.
There is no flag which you can set to enforce suppression of this exception...
You can suppress the exception and have the HTTP 401 status returned like any other HTTP response. Go to the IS Admin Extended Settings and set:
watt.net.http401.throwException=false
Note this is a server-wide setting, so it will affect all your applications/services that use pub.client:http.
According the comment from #Hugo Ferreira probably there are ACL restriction whether inside your webMethods environment, or your client URLs.
Things you should consider:
Do your webMethods server located inside closed environment wherein need to get connected to proxy to get to the outgoing request. Which is likely you can investigate by run web-browser program directly from your wM server towards the URL address (i.e using SSH to run firefox in my case and popup appeared)
The client that your request will go to, have HTTP for authentication requests
Solution
To pass this all you need to do is input the auth user/password or any other auth mechanism i.e kerberos, token, etc. inside the pub.client:http
When using ASP.Net Ajax to call PageMethods, how can I access the Http response headers from the "success" method?
For example:
PageMethods.DoSomething(
function(result){successMethod(result)},
function(error){errorMethod(error)}
);
function successMethod(result){
//------how can I access the Http response headers from here? ------
}
Thanks for any help
In your example, PageMethods.DoSomething should have a return value equal to WebRequest if it's an asp.net web service proxy. This is provided so that you can manipulate the request after you've initiated it (i.e. cancel it etc).
With this class you have an add_completed method which you can use to add a handler for when the web request completes. The signature for the callback is function OnWebRequestCompleted(executor, eventArgs), and the executor parameter in this enables you to get hold of extra response information. For example, you can get hold of the response headers with executor.getAllResponseHeaders(); which should be a map (named collection) of header names and values.
So if you add a handler to the web request's completed event immediately after making the service method call, it should work (there's no web service in the world that can respond faster than two consecutive lines of code!).
The previous hyperlink to WebRequest contains a full example of how wire this up. Notice, however, that this code uses the WebRequest directly.
Asp.Net Ajax Web Service proxy classes use the WebServiceProxy class, and each proxy method ultimately call its invoke method, which returns the WebRequest instance.
A web request has a headers collection
http://msdn.microsoft.com/en-us/library/bb383774.aspx
The webrequestmanager is a static object that you may be able to extract this information from:
http://msdn.microsoft.com/en-us/library/bb397435.aspx
Hopefully, between the two links, it makes sense :-;
I'm not saying recode to use this necessarily, but page methods is a wrapper and as such I think it would access information from a web request, which can be affected from the WebRequestManager...