I have a simple problem that I can't currently recreate and I need to solve next Monday.
In a development environment, we have a .NET4 service running on ASP.NET test server provided by VS2010 and a Java client running Axis2. We found that all requests fail. With Wireshark we found a 400 Bad request error on every request.
We found that each request from Java client required transfer-encoding: chunked. The rest seemed well formed. After the headers and a few bytes the server throws 400 error.
Questions are:
Does .NET test server support chunked transfers?
How can I tell Axis2 to use plain HTTP without even keep-alive just to be sure?
Answer 1
No, it doesn't. Disabling chunked encoding makes everything work!
Answer 2
http://wso2.org/library/209 provides information about how to disable chunked transfers (with an error in their code)
FooStub stub = new FooStub();
stub._getServiceClient().getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);
Related
I try to read the website https://www.eroids.com/reviews with Indy and always get a 403.
This website seems only to load when I set the ssl version to sslvTLSv1_1. If I do that, this website loads fine, but other websites not. Most other seems to use sslvTLSv1_2.
As long I only add [sslvTLSv1_1] to the sslversion, it works, but when I add [sslvTLSv1_1, sslvTLSv1_2], the mentioned site does not load anymore (again 403), but any other site does.
My question is: How can I determine what sslversion a website need? Do I need to try to access the site with each ssl version until I get a 200 back or is there something to me unknown integrated into indy to automatically do that?
How can I determine what sslversion a website need?
In general, you can't. However, most servers support version negotiation during the TLS handshake, so that clients supporting multiple/different TLS versions can negotiate with the server for which TLS version to use. But, it sounds like maybe this particular server does not support that.
However, the fact that you are even getting an HTTP 403 response at all for an HTTPS url means a TLS session is being created fine, so the issue is something else.
Unless the server is ignoring all TLS errors during the handshake and creating a simple TLS session, THEN is sending an HTTP error in reply to an earlier TLS error. Which is rare, but not unheard of.
Do I need to try to access the site with each ssl version until I get a 200 back
In this particular situation, probably so, yes. Start with [sslvTLSv1_1, sslvTLSv1_2], and if that fails then retry with [sslvTLSv1_2], then retry with [sslvTLSv1_1], and so on.
is there something to me unknown integrated into indy to automatically do that?
Indy does not have that capability at this time, no.
We have an ASP.NET WEBAPI application running on IIS 10.5 where we have offered a upload file API.
Since, we expect large files above 1 GB or so, we are performing some tests chunked transfer encoding.
It is observed that IIS 10.5 does not accept requests having transfer encoding set to Chunked.
On the .NET Framework side, we do have an option to use "bufferless" inputstream to avoid buffering and with this, we can avoid buffering on the receiving side but this is not same as chunked encoding.
API consumer applications send requests having chunked transfer encoding set and these requests are failing. Though, it is possible to ask consumer applications not to send this header, this can create a potential issue on the consumer side as all content gets buffered on the client side resulting in memory issue and it can eventually run out of memory.
As per HTTP 1.1, chunked encoding should be supported on both sender and receiver side. There is an argument in the forums that chunked encoding only applies to "Response" and not "Request". But it seems logical to support this on both side and HTTP 1.1 spec seems to talking about both ends though it is not explicitly mentioned.
For example, Apache HTTP Clients do support chunked encoding during the file uploads as well.
Is there a way to enable chunked encoding support? or is any reason why it is not supported in IIS 10.5 ? Any help / thoughts in this is really appreciated.
The AspEnableChunkedEncoding in IIS can enable chunked encoding:
https://learn.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms526005(v=vs.90)
There are similar issue in this blog.
I am using the latest version (1.0.0-beta-4) of James I. Armes php-ews code (https://github.com/jamesiarmes/php-ews) to connect to a local Exchange serge (Exchange 2010 SP1). This code connects just fine to Office/365, but it is getting ah 'HTTP 401 Unauthorized' back when it tries to connect to our local Exchange server. I have seen some old entries addressing similar problems, but none with a specific answer. Any suggestions on where to look?
I remember encountering something similar, where the server that I was using threw a 401 if you the SOAP client was trying to send a combination of CURLAUTH_BASIC and CURLAUTH_NTLM. I remember the solution was to try and find the SoapClient file and changing the CURLOPT_HTTPAUTH option to either CURLAUTH_BASIC, CURLAUTH_BASIC | CURLAUTH_NTLM or CURLAUTH_NTLM until you found the setting that worked for you.
On a side note, I'd recommend you trying my alternative library, garethp/php-ews, as it provides many benefits (including simpler ways to use EWS) and I try to provide support for people on the issues page
GETTING AN ERROR 'ERR_INVALID_CHUNKED_ENCODING' WHILE USING SQUID PROXY in Chrome. In other browsers, the page is not getting loaded. If proxy is not used the site is working fine in Internet.
The issue happens only where machines are connected through Squid proxy
squid-2.6.STABLE21.3.el5 doesn't fully support HTTP 1.1. Genrally it responds to HTTP 1.1 requests with HTTP 1.0 response. That is the problem. There are two ways to resolve it:
Solution 1
There is an experimental patch to add partial HTTP/1.1 support to
Squid-2 at http://devel.squid-cache.org/. This might work for you unless
your site is accepting POST/PUT requests.. (100-Continue is not yet
supported).
Solution 2
I heard that version 3.1 fully supports HTTP 1.1.
Please note that version 3.0 does not!
I'm having trouble with a long running webservice timing out in an Oracle 10g environment.
The client calls the webservice and after approximately 10 minutes, it receives the following response:
HTTP/1.1 503 Service Unavailable Server:
OracleAS-Web-Cache-10g/10.1.2.3.0 Content-Type: text/html Connection:
Keep-Alive Keep-Alive: timeout=600, max=999 Content-Length: 402
No
Response from Application Web Server No Response from Application
Web Server There was no response from the application web
server for the page you requested. Please notify the site's
webmaster and try your request again later.
The webservice executes a procedure in the database which takes a long time to finish (more than 20 min, on average) and the client receives the above response after aproximately 10 minutes.
My guess is that the webserver thinks the webservice has crashed, so it terminates it and sends the above response to the client.
My question is: how do I deactivate the timeout setting? I need to let the webservice run for as long as it needs (or, at least, for severeal hours).
I don't have access to the webserver's configuration or administration console but I can ask the guys responsible for managing it to change any setting (this is a test environment).
Thanks in advance for any ideas.