I have SOAPUI running mock REST and returing some json resonse, this part is working okay.
On the SoapUI server, I would like to save the binary file attachment from the client's REST request, which is coming from another client application not SOAPUI test request, to SOAPUI server side during processing of the client's request. Where do I start with this?
Thanks
We have Rest web services on a glassfish4 (payara) server
Our rest client is based on httpClient Lib
As Authentication we use certificate and basic auth.
The client work well getting and posting infos to WS
But when we send a multipart post with file bigger than few bytes, parsing the request hang until a timeout
If we disable the certification auth, all is working
Thanks to payara blog, we address the problem: we needed to change a configuration in payara, "Max Save Post Size" in Network Config->Network Listener -> http-listener-2 (the one using ssl) - http tab
I am developing an iPad application and using the ASIHTTPRequest library (https://github.com/pokeb/asi-http-request) to make requests to my web server, which runs CentOS 6.2 and is equipped with Apache 2.2 and mod_ssl enabled.
When I make an HTTPS request to the server, sometimes I get a null response. Absolutely nothing. As if the server were completely dead. Sometimes it works just fine, returning the expected response. There is no rhyme or reason to when the response is null and when it's fine.
The server uses a dummy security certificate
I am setting validatesSecurityCertificate to NO
I am setting SSLVerifyClient to none in httpd.conf
Note, HTTPS requests sent through a web browser work fine (after you tell it to proceed without a security certificate). But, all HTTPS requests sent through HTTP Client: ((Zero-length response returned from the server.))
The trick to using ASIHTTPRequest well is that you dont use it. Its deprecated by its author allseeing-i.com/ASIHTTPRequest . I suggest using AFNetworking, RESTKit or even NSURLConnection.
As it is we have no code of yours to see, but when experiencing random issues with a library that hasn't been worked on in years I would say to start by using a different library.
I have a webserver without content-coding (boa and not enough ressources). is there a possibility to put ziped javascript-file on the webserver and unzip it at the browser after downloading like content-coding?
In theory yes. You would need to add the Content-Encoding: deflate header to your http response.
You can not place a zip file created by a zip program on the server to be transferred, as it contains a header with the file structure before the deflate payload begins.
Also mind the differences between gzip and deflate. With gzip, similar is possible, too.
My company sells a LAMP-based (where P = Perl, not PHP) application deployed as an appliance. A customer is attempting to integrate their SiteMinder SSO with our application, such that our appliance sits behind a proxy running a SiteMinder Apache plugin that acts as a gatekeeper. For our application to authenticate a user via SSO, we expect to see HTTP requests that include an SSO cookie (SMSESSION in this case) and a custom HTTP header variable containing the username.
However, when our Apache server receives HTTP requests from the SSO proxy, all custom HTTP appear to have been stripped, although the cookie is present. I have instrumented the Perl code to write the headers to a log file with the following code:
my $q = new CGI;
...
my %headers = map { $_ => $q->http($_) } $q->http();
my $headerDump = "Got the following headers:\n";
for my $header ( keys %headers ) {
$headerDump = $headerDump . "$header: $headers{$header}\n";
}
kLogApacheError("info", $headerDump);
...and this is the output I get (slightly edited for confidentiality):
[Wed Mar 16 23:47:31 UTC 2011] [info] Got the following headers:
HTTP_COOKIE: s_vi=[CS]v1|26AE2FFD851D091F-4000012E400035C5[CE]; s_nr=1297899843493; [snip]
HTTP_ACCEPT_LANGUAGE: en-US,en;q=0.8
HTTP_ACCEPT_ENCODING: gzip,deflate,sdch
HTTP_CONNECTION: keep-alive
HTTP_ACCEPT: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13
HTTP_HOST: [redacted].com
IOW, the customer HTTP headers I'm expecting are missing. When we redirect traffic from the proxy to a different Apache server (i.e. not our appliance) all the 20+ custom headers show up as expected. This strongly suggests that it's our Apache server that is stripping the headers.
We have never run into a problem like this with other deployments, even with this particular SSO solution. I realize this is similar to another question on this site ( Server removes custom HTTP header fields ) but the suggestions there (such as a problem caused by running mod_security) don't apply.
Is there any other reason why our server might be stripping out the HTTP headers? Or is there possibly something else going on?
Thanks for any help!
Matt
Have you sniffed the raw HTTP traffic between the proxy and your Apache instance? If the necessary headers are missing herein, the problem is on the proxy side.
I finally figured this out, and it was pretty obscure...
Using HttpFox, it really looked like traffic was being redirected to the appliance rather than being forwarded. In the case of redirects, cookies were persisting but HTTP request headers were not. However, the SSO Proxy rules were all "forwards" so we were completely stumped as to why redirects were showing up.
We knew that our application's logic redirects to /signin/ if the user isn't already authenticated but we expected this would still be routed through the proxy. However, what we didn't realize is that there was a SiteMinder SSO option, enableredirectrewrite that by default would handle "any redirects initiated by destination servers [by passing them] back to the requesting user". Once we set this flag to "yes", and the redirectrewritablehostnames to "all", everything worked like magic.
(For reference, see a version of the SiteMinder manual here: http://www.scribd.com/doc/48749285/h002921e).
I recently had a problem where I could not get any custom HTTP Headers passed to my PHP Script.
It seems that Apache 2 running PHP 7 with FCGID would not allowing and removing or tripping all custom HTTP Headers.
Here is my fix:
http://kiteplans.info/2017/06/13/solved-apache-2-php-7-fcgid-not-allowing-removing-stripping-custom-http-headers/