Develop Reference

Why does my POST to Sagepay returns an Error 400?

I am trying to integrate my application with Sagepay, using the Server Integration Protocol. I have written my code in JAVA and currently I am at the point where I'm sending a POST to Sagepay to be redirected to their payment page. However, I get a blank screen which is a result of an Error 400 (Bad Request).
In their documentation, they specifically state that:
The data should be sent as URL Encoded Name=Value pairs separated with & characters and sent to the Sage Pay Server URL with a Service name set to the message
type in question.
The URL that I have constructed is this:
https://test.sagepay.com/gateway/service/vspserver-register.vsp&VPSProtocol=3.00&TxType=PAYMENT&Vendor=foovendor&VendorTxCode=foovendor-1459865650735-78597&Amount=10&Currency=GBP&Description=This+is+the+description&NotificationURL=http%3A%2F%2Fwww.google.com&BillingSurname=foosurname&BillingFirstnames=fooname&BillingAddress1=fooaddress&BillingCity=foocity&BillingPostCode=foopc&BillingCountry=UK&DeliverySurname=fooname&DeliveryFirstnames=foosurname&DeliveryAddress1=fooaddr&DeliveryCity=foocity&DeliveryPostCode=foopc&DeliveryCountry=UK&CustomerEMail=foo%40foo.com
What am I missing?
Thanks for your help!

Your url doesn't setup the query string properly.
Ithink that
register.vsp&VPSProtocol
should be
register.vsp?VPSProtocol
I.E. Question mark instead of ampersand.
Also, you said a post was required, but pasting that url in a browser will send a GET request, won't it ?

Decoding of umaut doesnt work when system.out is used in java

Our application download files using HttpClient. We take the filename from the HTTP Header and emit out as SysOut (System.out.println())
When there are non-USASCII characters like umlauts the sysout does not decode correctlty.
Ex: filename Textkürzung.txt is printed in sysout (And also in console) as Textk³rzung.txt
How can we encode this to UTF-8? Unfortunately we don't get the encoded character-set from the HTTP Headers

Encoding Turkish char on Http Post method with Java

I have a problem Turkish Character encoding
I send a xml document with web services on http post methods but When I encoding Turkish Character(Ğ,Ş ı...) asci code java translate &#230 etc.
this time url conneciton is cut data's other partial because & is mean new attribute
so how to solve this problem what can I do before send on java???

It seems you are sending the XML as part of the URL? In that case you'll need to percent-encode it (see RFC 3986)

jetty ,websockets and UTF8 encoding

I'm having a little problem. I'm building a small server in java, based on jetty websockets implementations.
The clients are the browsers and I send information using the websockets javascript api.
Everything works great until I send those special characters such as : ă Ț î ș ê ñ ü
So here is the problem. Client 1 sends a message to the server with one of this characters. Server prints the message and then send the message to client 2.
Client 2 receives the message and prints the message on a browser html page and works great The characters are showed correctly.
The problem is when I wanna print the String on the server site. Instead of ă is shows me the ? char. This is causing me problems because I want to insert the text in a database(mysql- with ut8 encoding enabled)
So.. what seems to be problem. The text that is send from the browser is not UT8 encoded? or the jetty websocket implementation is not receiving String in utf8 encoding??
Thanks

Here's a function I use to HTML-encode all special characters in a string (but not html itself (like < or >)). If you apply it before sending a string to the server, everybody should see the same and you can store it in a database table:
function toHtmlEncoded(string){
return string.replace(/[\u0080-\uC350]/g,
function(a) {return '&#'+a.charCodeAt(0)+';';}
);
}

First read this http://kunststube.net/encoding/
Then check everywhere you've converted bytes into Strings (or the reverse). Common places to make a mistake include calling getBytes() on a String without specifying an encoding. Other pitfalls include not setting the encoding in the database connection string.

Server side fix for receiving string containing '&'(ampersand)

We have already shipped a client (.NET WinForms) application which sends customer data to Java server. While most of the data sent by client are accepted at server side, some records are truncated because of the presence of & character in it, as client sends raw & and do not URL encode it, we have fixed it by using the below code:
string dataBefore="A & B";
string dataBefore = System.Web.HttpUtility.UrlEncode(dataBefore);
It is impossible for us to update all the client applications(which are already shipped) and we are thinking of a server side fix.
With the help of Fiddler, we have made sure the data has left client in full, but when server reads as below:
//in java
String dataReceied=request.getParameter("data");
it gets truncated if data contains &
Could someone help us suggesting a server side(java) fix for this? Is it possible to access the request stream in java(instead of request.getParameter())?

You can get access to the raw query string using HttpServletRequest.getQueryString() (javadoc), which:
returns a String containing the query string or null if the URL contains no query string. The value is not decoded by the container.
You can them perform manual decoding on that string, instead of using getParameter().
#Wesley's idea of using getParameterMap() may not be useful, because you don't know which order the parameters were supplied in.
I'd suggest implementing this logic as a servlet filter, to decouple the fixing of the broken parameters from your actual servlet logic. This would involve writing a custom subclass of HttpServletRequestWrapper which overrides getParameter() and manuyally decodes the query string. Your servlet would then be able to use the HttpServletrequest API as though everything was tickety boo.

It is cut off because & signifies a new URL parameter in a request like this:
google.com?query=java&page=2. Java converts all these parameters to a Map, so that's where it goes wrong.
Have you tried iterating through request.getParameterMap()? The remaining data is most likely in the name of the next parameter. If that does not work, check out the API of HTTPServletRequest to see if there is another way to get your data.
Good luck!
PS How angry are you guys at the intern that wrote & shipped that client? That sounds messed up!