We Keep Coding

How to make jboss accept %2F encoded slash in URL path

URL:http://localhost:8080/admin/users/8VHlQMoMAeGAfwADT%2FtM2Q%3D%3D
When i try to hit the above URL using advanced rest client, i am getting 400:Bad Request.
I need special characters to be passed in URl path via URL encoding only. But %2F is not being accepted.How to enable jboss to accept encoded slash in url? kindly help.

First of all you have to know that JBoss by default is not allowing the escaped slashes in paths for security reasons.
However you can set the following system property to true
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH

& becomes & during FTP to MVS

I am using a java library (edtftpj) to FTP a file from a web app hosted of a tomcat server to an MVS system.
The FTP transfer mode is ASCII and transfer is done using FTP streams. The data from a String variable is stored into an MVS dataset.
The problem is all the ampersand characters get converted to & . I have tried various escape characters including \& , ^& and X'50' (hex value), but none of it helped.
Anyone has any idea how to escape the ampersands please?

Nothing in the FTP protocol would cause this encoding behavior.
Representing & as & is an XML based escaping representation. Other systems might use the same scheme, but as a standard, this is an XML standard encoding.
Something in the reading of the data and writing of the data thinks it should be escaping this information and is doing the encoding.
If anything on the MVS system is using Java it is probably communicating via SOAP with some other connector, which implies XML, which could be causing the escape sequence to be happening.
Either way, the FTP protocol itself part is not part of the problem, ASCII transfer should only encode things like line endings, & is already a valid ASCII character and would not be affected. It is the MVS system that is doing this escaping if anything.
Binary transfer is preferred in almost every case, since it doesn't do any interpretation or encoding of the raw bytes.

Using FTP in ASCII-mode to/from a MVS (z/OS) will always perform code page conversions (i.e ASCII <-> EBCDIC) for the data connection. Thus it's very important to setup the connection with the appropriate parameters depending on dataset type and page codes. Example:
site SBD=(IBM-037,ISO8859-1)
site TRAck
site RECfm=FB
site LRECL=80
site PRImary=5
site SECondary=5
site BLKsize=6233
site Directory=50
As alternative, use BINARY mode and manually perform the conversions with some of the standard tools or libraries on the receiving end.
Ref links:
1. Preset commands to tackle codepage problem.
2. Coverting ASCII to EBCDIC via FTP on MVS Host.
3. Transferring Files to and from MVS.
4. FTP code page conversion.
5. FTP File Transfer Protocol and Z/OS (pdf).

Sending Arabic Text via Java Web Service

I am getting special characters(?????) on my mobile when I send arabic text through JAVA Webservice. Below is the whay how I implemented.
Webservice Client and Test program is on my windows PC and I am running from Eclipse whose char set is ISO-8859-1.
In my Test Program I am encoding (using URLEncoder) the Arabic String to ISO-8859-6.
WebService Host is Installed on Linux server. Here I am converting the encoded string to bytes. Then I am forwading this request to java service over TCP IP. This service is responsible to send SMS.
In this Java service I am decoding with same encryption as above and posting to SMS provider.
Implementation
/**
* Arabic Implementation is as below
**/
String message= arabictext;
message=URLEncoder.encode(message,"ISO-8859-6");
sendMessage(message,uername,password); ///webservice call
Web Service Host coding:
sendMessage(p_message,username,password){
byte[] request = message.getbytes();//tried by passing character set
Tcserver.post(request);//posting the request to java client
}
Note: Both Webservice Host and java client are hosted on same physical server.
Java Client :
sendSMS(p_message){
message =URLDecoder.decode(p_message,"ISO-8859-6");//send message to mobile provider.
sendmessagetoProvider(message);
}
when I ran TCPViewer on my PC I am seeing special characters. Any idea how to fix this issue.

I think that the problem is somewhere into your sendmessagetoProvider as well as in usage for URLEncoder and URLDecoder.
When you are sending message you probably have to encode it. You are calling decode at client side instead. BTW IMHO this is the reason for "special characters" you receive.
So, first take a look on your API specification. What is method sendmessagetoProvider expecting? Probably you do not have to encode the string as URL? Probably it just supports Unicode or you have to provide the encoding when you are calling client? Then fix you code accordingly.
Good luck.

Unescaping / decoding an email address set in a cookie

I've stored an email address in a cookie, and I'm sending it to a jsp file on google appengine to be verified. The # is coming through as %40. I need to get it back to an #, and convert any other special chars that might have been encoded. Are there classes available through appengine that deal with this conversion?

Look at URLDecoder and URLEncoder:
http://download.oracle.com/javase/6/docs/api/java/net/URLDecoder.html
Looking at the JRE whitelist they are both fine to use.

Handling Character Encoding in URI on Tomcat

On the web site I am trying to help with, user can type in an URL in the browser, like following Chinese characters,
http://localhost:8080?a=测试
On server, we get
GET /a=%E6%B5%8B%E8%AF%95 HTTP/1.1
As you can see, it's UTF-8 encoded, then URL encoded. We can handle this correctly by setting encoding to UTF-8 in Tomcat.
However, sometimes we get Latin1 encoding on certain browsers,
http://localhost:8080?a=ß
turns into
GET /a=%DF HTTP/1.1
Is there anyway to handle this correctly in Tomcat? Looks like the server has to do some intelligent guessing. We don't expect to handle the Latin1 correctly 100% but anything is better than what we are doing now by assuming everything is UTF-8.
The server is Tomcat 5.5. The supported browsers are IE 6+, Firefox 2+ and Safari on iPhone.

Unfortunately, UTF-8 encoding is a "should" in the URI specification, which seems to assume that the origin server will generate all URLs in such a way that they will be meaningful to the destination server.
There are a couple of techniques that I would consider; all involve parsing the query string yourself (although you may know better than I whether setting the request encoding affects the query string to parameter mapping or just the body).
First, examine the query string for single "high-bytes": a valid UTF-8 sequence must have two or more bytes (the Wikipedia entry has a nice table of valid and invalid bytes).
Less reliable would be to look a the "Accept-Charset" header in the request. I don't think this header is required (haven't looked at the HTTP spec to verify), and I know that Firefox, at least, will send a whole list of acceptable values. Picking the first value in the list might work, or it might not.
Finally, have you done any analysis on the logs, to see if a particular user-agent will consistently use this encoding?