I host a 10 year old java (jar) based web service on Tomcat.
The original source for this service no longer exists (actually the firm that created the service no longer exists and there doesn't seem to be any way to find the former principals).
I packet captured the "Data" field in the url and include a snip of it below.
I'm hoping someone will recognize the encoding used on this field - it does not appear to be standard where the rest of the URL encoding it no problem. So I'm thinking the application posting the data field first encodes the field (which is then again encoded for the URL post command.
http:// ... &CompletedBillableTransactionFlag=&Data=%F0j%B2g%1F-%95%F7%E3E%C0q%A6%12%11%B2%7C%D8%C7%F6%C8%24 ... I could have included the rest of the fields value but thought to keep it short.
Related
I am working with a piece of web software that uploads files to a camel-jetty server. The uploads happen through BlueImp jQuery FileUpload (https://github.com/blueimp/jQuery-File-Upload) through the browser. The company I work for recently upgraded from Camel 2.3 to Camel 2.17 in our server-side Java project. We never had a problem before, but since we upgraded to the newer version the file uploads no longer work. Digging into it I have discovered a few strange things:
exchange.getIn().getAttachments().size() == 0 (always)
A NullPointerException is ALWAYS thrown in MultiPartFilter inside camel-jetty because it attempts to ALWAYS get the content-type of EVERY form-data part... even though every browser/agent I have tested by default will not set the content-type on every part.
I fixed the NullPointerException in jetty MultiPartFilter by following advice from another post that uses FormData and Blob directly in javascript to force a content-type on every form-data part (Composing multipart/form-data with a different Content-Type on each parts with Javascript (or Angular)). However, the exchange.getIn().getBody() is now always null, and exchange.getIn().getAttachments() is still always an empty list.
Upon closer inspection I noticed binary data on a header sent AS THE FILE from jQuery FileUpload. exchange.getIn().getHeader("files[]") is a binary data stream, but the data appears to be mangled... I assume because it is being converted to UTF8 encoding (or visa-versa) before it is set on the header.
So my question is how does a person upload files via camel-jetty? I can not find a single example that works when used in the real world with camel-jetty 2.17.0. All examples used to work on Camel-Jetty 2.3.
What am I doing wrong? Can someone please post a working example of a file upload processor using camel-jetty 2.17?
I have developed an application which contacts a Sun One web server. The Web Server has Lotus domino and SiteMinder Plugin.
Below is the URL for the application
http://HostName.example.com
After hitting the URL in the browser, the URL is redirect to webserver and a login page appears with below URL.
http://HostName.example.com:9898/SiteMinderagent/forms/login.fcc?TYPE=
33554433&REALMOID=06-1716e557-15f3-100f-b9a4-835cc8200cb3&GUID=&SMAUTHREASON=
0&METHOD=GET&SMAGENTNAME=$SM$sHjbzl4f9R%2bcSa0%2fEgnu6oUQQPMQnUgkU6Zvx5zWZpQ%
3d&TARGET=$SM$http%3a%2f%2fshivalik%2ered%2eiplanet%2ecom%3a9898%2fvalidation%
2findex%2ehtml
After logging into the application, the request is redirect using the TARGET parameter( URL is decoded in the application) from the URL Now the login doesnot work if i block the HTTP requests. As the TARGET parameter is a HTTP request, I am unable to login into the application.
Is there any way I can change the TARGET parameter to HTTPS. Can i know in which file I can change it in the WebServer. The Sun One Web Server runs Solaris OS. I have tried hard finding the solution as I think the URL is appended with Query strings like SMAGENTNAME, SMAUTHREASON, TARGET in the Servlet of the Domino.
The TARGET parameter is populated with the URL originally presented by the user - i.e. in your example http://HostName.example.com will result in the TARGET query string parameter containing the same URL plus the other parameters generated by the SiteMinder agent.
Possible solutions in your case could be to hardcode the TARGET by putting something like the following on the top of login.fcc:
#TARGET=https://hostname.example.com/
That would cause the FCC to ignore the query string parameter that is POSTed and instead will hardcode it.
Alternatively if you need to preserve the path component of the URL (e.g. http://hostname.example.com/path/to/file.html) you could add some javascript to the FCC page. The standard implementation populates TARGET into an element so you could use JavaScript to parse the value and replace http:// with https:// if required. Make sure that your Agent Configuration has single and double quotes in BadFormChars (BadFormChars=%22,%27) to prevent XSS attacks.
There is also an Agent Config parameter HttpsPort that you can use to "trick" SiteMinder into thinking you're serving HTTPS traffic out of port 80 but you will have to test for any unintended side effects.
I have to set up a connection to a webservice that I don't own, all I have is a link to the WSDL file. The webservice has only one method, and I need access to it. I'm trying to use the standard "Generate Java Code from Wsdl or Wadl" (or create New->Web Service Client, which ends up in the same spot)
When I enter the URL I have, the status line says "Wsdl url connection exception". If I put the url in a browser, it nicely displays the xml file, so the URL works. I have a similar problem trying to generate the code in eclipse, where it also refuses to acknowledge the URL.
It's the first time I do anything webservice related and it's driving me mad, how do I fix this?
i want to write some code in java to find out if a given url is a file or a directory. how can i do this??
URLs themselves don't have the concept of being a "file" or a "directory". The content of a URL is defined by whatever the server responds with when requested. If you get something with a MIME type of application/pdf, then the URL represents a PDF file. If you get anything else, then it's not a PDF file.
There is simply no notion of a "directory" in any of the URL / URI specs, the HTTP specs or the MIME type registry.
So the webserver has no way of telling the client that a URL resolves to a directory ... even if it knows what that means. (And in many cases, the webserver doesn't know / care about directories itself; e.g. a typical RESTful web API doesn't recognize the concept.)
Your options are:
Try to fetch things and see what content type you get. But bear in mind that a "directory" might be rendered by the webserver as anything ... so it is (in general) impossible to reliably distinguish directories from non-directories this way.
If you wanted to avoid downloading the file, you could send a HEAD request instead of a GET request. This requires the use of a fully fledged HTTP client library rather than URLConnection.
Change your application design and implementation so that the "directory" concept is not required.
Change your application so that it decides what is a "directory" and what is a "file" based purely on the URLs. (In the general case, this won't work ... because there are no universally observed conventions for URL name parts that would allow you to make the distinction.)
Change to using a URL scheme / protocol in which "directory" is a well-defined concept. For instance "file:" or "ftp:".
What you get back from a URL essentially isn't a "file" or a "directory." At best, it's a stream of data with a content type. It generally becomes a "file" on the client side, either by means of saving it to a file system or to a temporary store for display only. Basically, there's no way for a web server to tell a client that something is a directory using HTTP.
You're either going to have to create some client-side business logic to infer a "directory" (possibly based on the URL, maybe a lack of file extension?) or use a different protocol for this.
I'm downloading various files through I/O-streaming in my Java application. Receiving and saving those files works well as long as I have a full URL-path including file name, but how can I find out the name of the index file (as defined in, for example, Apache's DirectoryIndex) of a domain? The HTTP header doesn't provide this information and neither does the URLConnection method.
Thanks alot!
Be well
S.
As far as I know there is no way of retrieving this information. The HTTP specification doesn't provide it, and I think this isn't a bad thing. Your clients requests the URL "/", it's up to the web server how to handle that, there is no obligation to return a filename too.
It's also worth pointing out (I'm sure you're aware of it but just in case) that just because a URL looks like /somedir/somefile.html, it doesn't mean that is the actual file being served. It could be being served via a proxy to another host, mod_rewrite etc - in other words, the name as arbitrary and doesn't necessarily bear any relation to the physical name on disk.
In short, I think your best bet would be to pick a default filename e.g. index.html for those cases and stick to it.
Only way out is to:
Inspect Content-Disposition header and use it to generate filename. If server is serving a file, it would set this header. E.g. http://server:port/DownLoadServlet URL might set this header to indicate name as "statement.pdf".
IF this header is missing, use Heuristics to generate filename. This is what browsers do to generate filenames like Doc[10].pdf Doc[12].pdf etc.
Use content-type header (if available) to guess file extension.