I have written client side rest services on php and the server side is on Java.
I am sending a value அகம்.com.my using the client side webservice and trying to perform some operation on the server side. The received value is à® à®à®®à¯.com.my
what can I do to receive the string in the same format. I tried to encode the value into base64 and decoded on the server side but still the received value is different.
Make sure you add a 'content-type' header in your requests.
You need to inform the server what kind of data you're sending so it will know how to process it correctly.
For example, if you're sending plain text in UTF8, you can add the following line in your client code :
header('Content-Type: text/html; charset=utf-8')
Fixed it so posting the solution.
on php end:
urlencode($domainName);
Decoded and used UTF-8 on the server side (java):
domainName= java.net.URLDecoder.decode(domainName, "UTF-8");
Related
In restfull WS, how to tell client to send only csv and text format file.
In content-type header, client set the format in which it is sending request and in Accept header, client set the format in which it want to accept response.
But how to tell client to send only content-type csv or file ? Is this through some documentation ?
The 415 status code seems to be suitable for this situation:
6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.
The response payload could contain a list of the media types supported by the server.
Image you have an endpoint called /textfiles - the developer using your API is usually reading your documentation on how to implement this endpoint. Unless you're not doing some auto-discovery magic (which I guess is still not common).
If we take Facebook for example, they just state in their documentation which files you can send:
We accept the following files: 3g2, 3gp, 3gpp, [...]
Your question:
But how to tell client to send only content-type csv or file ?
is also a bit unclear. When the user has sent the request, he already attached the files he thought he could send. So here you would rather send an error with a message, which files are allowed. So are we talking about some "pre"-requests here?
From a backend developers point of view I can just tell you: It's in the documentation. Handle errors properly, document and your implementing developer will not hate you :)
if i develop a restful application using spring i would set the produces attribute to return csv or plain text ( https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/annotation/RequestMapping.html) . if the client tries to request a resource other than csv or text it will recieve an error . probably 415
GET call on REST API with Accept as text/csv and content-Type as application/json. In what format should the reponse be?
Should the response be in JSON format or in CSV format?
In HTTP, the Accept header is used by the client to tell the server what content types they'll accept.
The server will then send back the response and will set the Content-type header telling the client the type of the content actually returned.
You might have noticed that Content-type is also included in some HTTP requests. This is because some type of HTTP requests, like POST or PUT, can send data to the server. In this case the client tells the server the type of the content data, using the Content-type header.
Now to your question, a GET request should not have any Content-type header. I hope this is clear after my explanation above.
As you correctly note, the Accept header is used by HTTP clients to tell the server what content types they'll accept. The server will then send back a response, which will include a Content-Type header telling the client what the content type of the returned content actually is.
However, as you may have noticed, HTTP requests can also contain Content-Type headers. Why? Well, think about POST or PUT requests. With those request types, the client is actually sending a bunch of data to the server as part of the request, and the Content-Type header tells the server what the data actually is (and thus determines how the server will parse it).
In particular, for a POST request resulting from an HTML form submission, the Content-Type of the request will (normally) be one of the standard form content types below, as specified by the enctype attribute on the tag:
application/x-www-form-urlencoded (default, older, simpler, slightly less overhead for small amounts of simple ASCII text, no file upload support)
multipart/form-data (newer, adds support for file uploads, more efficient for large amounts of binary data or non-ASCII text)
source: https://webmasters.stackexchange.com/users/12578/ilmari-karonen
based on that, you should go for the parameter Accept!
I am in the process of sending a HTTP chunked request to an internal system. I've confirmed other factors are not at play by ensuring that I can send small messages without chunk encoding.
My process was basically to change the Transfer-Encoding header to be chunked and I've removed the Content-Length header. Additionally, I am utilising an in-house ChunkedOutputStream which has been around for quite some time.
I am able to connect, obtain an output stream and send the data. The recipient then returns a 200 response so it seems the request was received and successfully handled. The endpoint receives the HTTP Request, and streams the data straight into a table (using HttpServletRequest.getInputStream()).
On inspecting the streamed data I can see that the chunk encoding information in the stream has not been unwrapped/decoded by the Tomcat container automatically. I've been trawling the Tomcat HTTPConnector documentation and can't find anything that alludes to the chunked encoding w.r.t how a chunk encoded message should be handled within a HttpServlet. I can't see other StackOverflow questions querying this so I suspect I am missing something basic.
My question boils down to:
Should Tomcat automatically decode the chunked encoding from my request and give me a "clean" InputStream when I call HttpServletRequest.getInputStream()?
If yes, is there configuration that needs to be updated to enable this functionality? Am I sending something wrong in the headers that is causing it to return the non-decoded stream?
If no, is it common practice to wrap input stream in a ChunkedInputStream or something similar when the Transfer-Encoding header is present ?
This is solved. As expected it was basic in my case.
The legacy system I was using provided handrolled methods to simplify the process of opening a HTTP Connection, sending headers and then using an OutputStream to send the content via a POST. I didn't realise, and it was in a rather obscure location, but the behind-the-scenes helper's we're identifying that I was not specifying a Content-Length thus added the TRANSFER_ENCODING=chunked header and wrapped the OutputStream in a ChunkedOutputStream. This resulted in me double encoding the contents, hence my endpoints (seeming) inability to decode it.
Case closed.
I am debugging an application which gets a bad Request, Response from JAX-RS. I have monitored the HTTP message using TCPMon and figured out that The MIME boundary in Header does not match the Boundary in message parts.
What I am trying to do is, Writing a simple java program that changes that boundary of the message part according to the header MIME boundary.
but When I edit the String and sent it back to the JAX-RS service I get errors like Unexpected EndOfLine,Uxexpected EOF.
What I did was , opened a server socket and read the message from incoming connection from my application and edited the MIME boundary of Message parts
String mimeBoundary = message.toString().split("\r\n")[5].split(";")[1].split("=")[1];
message.replace(message.indexOf("MIMEBoundary"), message.indexOf("MIMEBoundary")+61,mimeBoundary);
message.replace(message.indexOf("MIMEBoundary"),message.indexOf("MIMEBoundary")+61,mimeBoundary);
And send the Message(String) to the JAX-RS service.
What am I doing wrong here? someone please help.
Thank You.
I'm using java code for sending JSON data to flash for that I'm using netty server 4.0.23.
By that I'm using two different data to send to the same client frequently. I used channel.writeAndFlush(). So far everything happens good, while receiving data in client both the data are merged together and gives Invalid Json.
I traced the sending data in java there it is in correct format. It is getting invalid while receiving in client side. The two different JSON data are merged into a single JSON Data, so that the Invalid Json type error is occuring. If I put timer delay in between the two data, then the data are correctly received in client side. How can I receive proper data without applying the delay inbetween the data while sending.....
I used the following pipelines
pipeline.addLast(new DelimiterBasedFrameDecoder(8192, Delimiters.lineDelimiter()));
pipeline.addLast(new StringDecoder());
pipeline.addLast(new StringEncoder());
pipeline.addLast("handler", new ServerHandler());
It sounds like your client (the receiving part) does not handle the received JSON messages properly. TCP is streaming protocol, which means two writes on one side can be seen as one read on the other side. For example, when a server sends "A" and "B", a client will not always see "A" and "B" but will sometimes see "AB", and it's fully fine.
To deal with this sort of situation, you need to 'frame' a message. It is usually done in Netty by inserting a framing decoder.
In your case, the client is written in Flash, so you'd better simply use XMLSocket and let your server delimit each JSON message with NUL (0) byte.
If you are interested in framing, please read the Netty user guide.