I am using Play framework (Java) to create REST apis for my application.
I am facing problem with length of REST API with GET.
I need below web method to be used:
public static Result getregistereduser(String userlist)
{
//userlist is string of user numbers seperated by "$" ,
.....
....
}
in routes I have :
GET /getregistereduser controllers.Application.getregistereduser(userlist)
Problem I am facing is when userlist is large it only takes partial string.
I'm not sure what version of Play you're using, but Play shouldn't truncate long GET requests. You should get an error response if the GET request is too large for it to handle.
Up until recently that error would be a 500 Internal Server Error caused by an org.jboss.netty.handler.codec.frame.TooLongFrameException. With Play 2.3.0 (not yet released) you'll get a 414 Request URI too long response instead.
Play inherits its HTTP header parsing from Netty. The first line of the header (GET /path HTTP/1.1) can be up to 4096 bytes by default. This can be configured by with the http.netty.maxInitialLineLength system property (see this mailing list thread).
I agree that you're most likely seeing problem with your HTTP client. I'd recommend using a debugging proxy like Charles (or a free alternative) to look at exactly what HTTP requests your client is sending.
Related
Suppose I have a resource that is hosted on a websocket server, and I wish to validate the response status code 101, after the connection is upgraded, how and which libraries to use.
Im currently looking at jayway response library, when I connect to a websocket resource, initially it sends a 200 and then upgrades to 101. So code returns 200, I would like to know how this library can be used for websocket validation.
Sample code is :
String response =given().get()("https://www.ws.com:444/examples/websocket/snake.xhtml")
.getResponse().asString();
This returns a 200, but does not return the next response. I might sound a little rusty here, would appreciate if you folks have any idea how to extend it to get status 101 or if you have any other suggestions.
Also, this requirement needs to be extended to handle redirection 30x status codes as well, assume a resource is protected behind an access gateway, when a request comes for this protected resource, the gateway forwards it to identity store for verifying the user, at this time a 302 is returned, once verified, request is sent back to access gateway from where user is able to access websocket resource.
We are developing an application that allows a user to upload file on rest end point.
Could someone please guide if it is correct to send 400 error code for the failure of following validation scenario:
1) The Length of file name exceeds permissible limit.
2) File name contains special characters
3) Uploaded file was empty
4) The System failed to read the uploaded file from disk.
Regards,
Tarun
The Length of file name exceeds permissible limit.
I think the 400 is not an appropriate because syntax of the request is correct in this case. The 422 Unprocessable Entity is better in this case.
File name contains special characters
Illegal characters mean the syntax is broken. So 400 Bad Request is a proper response in this case. Someone may claim that a definition of illegal characters is needed so the server may authoritatively send 400.
Uploaded file was empty
I think it is not an error because an empty file is a legal file.
The System failed to read the uploaded file from disk.
Does the system mean the server? Then the server should return a 5xx response because it is not a client failure. In case of general read error the server should return 500.
EDIT:
Uploaded file was empty.
When application semantic forbids an empty file the 400 or 422 appropriate. More details about them is at 400 vs 422 response to POST of data
4xx statuses are for client-side errors, 5xx are for server-side errors. So, generally you need 4xx codes for your cases 1) to 3), while 4) should be a 5xx error.
Let’s first say that for your case 4), a simple HTTP 500 seems appropriate. If you want to indicate that the client could try again later, HTTP 503 would be more suitable.
Now for 1) to 3): According to RFC 2616, HTTP 400 indicates syntax errors; this would usually be protocoll errors, e.g. invalid headers. Semantical or payload errors aren’t really defined in this generic RFC, however, (as Zaboj mentions) WebDAV offers HTTP 422, which seems suitable, though it’s not really meant for generic HTTP.
In the end, it doesn’t really matter which particular codes you send. If your upload fails with HTTP 400 or 422, in either case the client will perform some error routine (e.g. show or log the error message).
The important thing to know is that some codes can trigger client behaviour (e.g. HTTP 401 combined with certain headers can trigger an authentication dialog in a browser), and you should be aware of these side effects.
In my opinion, it is much more important to send a useful error description in the response body to help the client fix their problem, than finding the “perfect” HTTP status code. I know that REST zealots will disagree, but none of them will be able to give you the right HTTP status code for every situation.
That said, if you want to issue fine-grained error codes/messages for automated processing, you can introduce custom HTTP header fields, e.g.
X-MyApp-Error-Code: 2.1.6
X-MyApp-Error-Message: The uploaded file is empty
Then you would provide a documentation and/or SDK which reveals all possible error code values for X-MyApp-Error-Code to your API consumers.
In trying to serve GWT permutations out of the blob store in order to escape the AppEngine hard limit of 150 mb for static files, I've succeed in doing so for "html" and image files "jpeg, png, .etc" and other .rpc calls, but am hung up on XSRF calls.
In the server logs, I see:
The serialization policy file '/theapplication/CCA65B31464BDB27545C23C142FEEEF8.gwt.rpc' was not found;
My upload log shows it was uploaded /CCA65B31464BDB27545C23C142FEEEF8.gwt.rpc : HTTP/1.1 200 OK
The request url shows http://14.applicationXYZ.appspot.com/xsrf
the RequestPayload shows: http://14.applicationXYZ.appspot.com/theapplication/|CCA65B31464BDB27545C23C142FEEEF8|com.google.gwt.user.client.rpc.XsrfTokenService|getNewXsrfToken|1|2|3|4|0|
Other rpc calls are resolving (via a server filter is looking for /theapplication and mapping the requests to a blob to serve) as in the following case where an rpc call is made without an Xsrf request (as the user is not logged in yet)
req url -- http://14.applicationXYZ.appspot.com/someRPCCall
RequestPayload -- http://14.applicationXYZ.appspot.com/theapplication/|62D7E6737056C685E10947B640409549|com.abc.client.rpc.Service|doWork|java.lang.String/2004016611|java.lang.Boolean/476441737|wwwerr|1|2|3|4|3|5|5|6|7|7|6|0|
So, I have two questions:
1) why is XSRF call failing to return the appropriate blob, ie. why doesn't the xrsf call get handled by the filter the way other url calls to /theapplication/* do?
2) What can I do about it?
3) Also, I tried setting the content type to "text/x-gwt-rpc; charset=UTF-8 and also as unspecified when I uploaded the blob. Anyone know what the content type should be for *.gwt.rpc in case I do get the xrsf working? Could having the wrong content type be causing the trouble?
***note applicationXYZ is not the real name so no the links won't work.
OK /xsrf is mapped to a servlet as well, so if the filter returns a blob without passing on the filter, it seems it won't reach the servlet.
Anyway, it's easy enough just to upload the few .rpc files as normal and not serve them as blobs.
I'm trying to create an android app to check my tests scores of my engineering school. In order to download the Word containing the scores, I need to login to the portal.
I thought it would be simple to do it by sending a POST request.
After bypassing the problem of the self-signed certificate (or whatever) thanks to the code on this page : Self-signed SSL acceptance on Android
I still get an 500 error while trying to send any POST request to the login page, which is here : https://e-campus.hei.fr/ERP-prod/pc_mv_login.aspx
I tried various codes from the web to send the POST data (especially How to do a HTTP Post in Android? this one). And even on a pure java app, I get a 500.
When I point the URL to another testing page, I manage to get it working, but not on https://e-campus.hei.fr/ERP-prod/pc_mv_login.aspx
Could anyone explain to me why it doesn't work or help me get rid of this error ?
EDIT:
This is what is being sent through my browser (According to chrome developper tools)
__EVENTTARGET:
__EVENTARGUMENT:
__VIEWSTATE:dDwxNDU4ODc4MDI5O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDE+O2k8Nz47aTwxMz47aTwxNT47aTwxNz47aTwxOT47PjtsPHQ8cDxwPGw8VGV4dDs+O2w8SWRlbnRpZmlhbnQgOjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8TW90IGRlIHBhc3NlIDo7Pj47Pjs7Pjt0PHA8cDxsPFRleHQ7PjtsPExhbmd1ZSA6Oz4+Oz47Oz47dDx0PDt0PGk8Mj47QDxBbmdsYWlzO0ZyYW7Dp2Fpczs+O0A8ZW47ZnI7Pj47bDxpPDE+Oz4+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Vm91cyBuJ8OqdGVzIHBhcyBhdXRvcmlzw6kgIMOgIHZvdXMgY29ubmVjdGVyLjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Q29ubmVjdGVyIDo7Pj47Pjs7Pjs+Pjs+Pjs+inmhCwE9zfymuEXDXGORShkB1GI=
Username:******
Password:******
Langues:fr
Button1:Connecter :
This is the string that i send :
String parameters = "__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE="
+ URLEncoder
.encode("dDwxNDU4ODc4MDI5O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDE+O2k8Nz47aTwxMz47aTwxNT47aTwxNz47aTwxOT47PjtsPHQ8cDxwPGw8VGV4dDs+O2w8SWRlbnRpZmlhbnQgOjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8TW90IGRlIHBhc3NlIDo7Pj47Pjs7Pjt0PHA8cDxsPFRleHQ7PjtsPExhbmd1ZSA6Oz4+Oz47Oz47dDx0PDt0PGk8Mj47QDxBbmdsYWlzO0ZyYW7Dp2Fpczs+O0A8ZW47ZnI7Pj47bDxpPDE+Oz4+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Vm91cyBuJ8OqdGVzIHBhcyBhdXRvcmlzw6kgIMOgIHZvdXMgY29ubmVjdGVyLjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Q29ubmVjdGVyIDo7Pj47Pjs7Pjs+Pjs+Pjs+inmhCwE9zfymuEXDXGORShkB1GI=",
"UTF-8") + "&Username="
+ URLEncoder.encode(mUsername, "UTF-8") + "&Password="
+ URLEncoder.encode(mPassword, "UTF-8")
+ "&Langues=fr&Button1="
+ URLEncoder.encode("Connecter :", "UTF-8");
HTTP error 500 just means that the server side code failed. It has a bug, for example a NullPointerException was been thrown over there. If the response body doesn't contain anything sensible (e.g. a stacktrace) so that you could learn how it is caused and so change the request accordingly, then your best bet is to contact the server admin and report about this bug in the server code and ask how to correctly perform a programmatic login.
If that is not an option for some reason, then you should doublecheck if you don't forget to send a specific cookie, header and/or parameter. Probably the server side code was expecting it, but it was null and the code was buggy and hence it totally broke with a 500. I'd suggest to use Firebug to track the entire HTTP traffic and compare it with the headers/parameters you've set. Probably you need to send a specific cookie back? Or you need to send the name=value pair of the submit button? Etcetera.
Update: you're sending the wrong __VIEWSTATE value along. The website runs on ASP.NET MVC which is a component based MVC framework (like as JSF in Java EE). It stores the component tree as "view state". You should not send a random/non-existing/invalidated view state back as paramter, but a valid one. You need to rewrite the HTTP client so that it first fires a GET request on the page with the form and then use a HTML parser (Jsoup?) to extract the value of the hidden __VIEWSTATE input field and finally fire a POST request with exactly that value (and exactly the same cookie in the request header!).
Like as in JSF, the view state is part of CSRF attack prevention. You cannot submit the form without first requesting the form from the website itself in the same session.
All,
I'm trying to find out, unambiguously, what method (GET or POST) Flash/AS2 uses with XML.sendAndLoad.
Here's what the help/docs (http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00002340.html) say about the function
Encodes the specified XML object into
an XML document, sends it to the
specified URL using the POST method,
downloads the server's response, and
loads it into the resultXMLobject
specified in the parameters.
However, I'm using this method to send XML data to a Java Servlet developed and maintained by another team of developers. And they're seeing log entries that look like this:
GET /portal/delegate/[someService]?svc=setPayCheckInfo&XMLStr=[an encoded version of the XML I send]
After a Google search to figure out why the POST shows up as a GET in their log, I found this Adobe technote (http://kb2.adobe.com/cps/159/tn_15908.html). Here's what it says:
When loadVariables or getURL actions are
used to send data to Java servlets it
can appear that the data is being sent
using a GET request, when the POST
method was specified in the Flash
movie.
This happens because Flash sends the
data in a GET/POST hybrid format. If
the data were being sent using a GET
request, the variables would appear in
a query string appended to the end of
the URL. Flash uses a GET server
request, but the Name/Value pairs
containing the variables are sent in a
second transmission using POST.
Although this causes the servlet to
trigger the doGet() method, the
variables are still available in the
server request.
I don't really understand that. What is a "GET/POST hybrid format"?
Why does the method Flash uses (POST or GET) depend on whether the data is sent to a Java servlet or elsewhere (e.g., a PHP page?)
Can anyone make sense of this? Many thanks in advance!
Cheers,
Matt
Have you try doing something like that :
var sendVar=new LoadVars();
var xml=new XML("<r>test</r>");
sendVar.xml=xml;
sendVar.svc="setPayCheckInfo";
var receiveXML=new XML();
function onLoad(success) {
if (success) {
trace("receive:"+receiveXML);
} else {
trace('error');
}
}
receiveXML.onLoad=onLoad;
sendVar.sendAndLoad("http://mywebserver", receiveXML, "POST");
The hybrid format is just a term Macromedia invented to paint over its misuse of HTTP.
HTTP is very vague on what you can do with GET and POST. But the convention is that no message body is used in GET. Adobe violates this convention by sending parameters in the message body.
Flash sends the same request regardless of the server. You have problem in Servlet because most implementation (like Tomcat) ignores message body for GET. PHP doesn't care the verb and it processes the message body for GET too.