Why two calls to HttpSendRequest on different connections (new InternetOpen and new InternetConnect) bring different results? - c++

I'm using wininet to connect to a url that needs a client certificate. To test my "automatic error correction", I'm doing this connection without the client certificate and the behaviour is to call my SelectCertificate function.
Intentionally I do not pass all the parameter to this function wich, of course, raises an exception and my request is aborted. There are cleaning blocks to do all the necessary cleaning [InternetCloseHandle(HttpOpenRequestHandle), InternetCloseHandle(InternetConnectHandle) and InternetCloseHandle(InternetOpenHandle)].
The first request is returnig the correct exception, caused by the lack of a client certificate, but the second (new?) request is raising another exception "Secure Channel Support Error" (error 12157)
To clarify, see the following flow:
The first request
1.0 InternetOpen(...)
2.0 InternetConnect(...)
3.0 HttpOpenRequest(...)
4.0 HttpSendRequest(..)
4.1 Error (ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED)
4.2 SelectCertificate
4.2.1 Raise exception because I intentionally do not passed all parameters
5.0 InternetCloseHandle(HttpOpenRequestHandle)
6.0 InternetCloseHandle(InternetConnectHandle)
7.0 InternetCloseHandle(InternetOpenHandle);
The second (new?) request
1.0 InternetOpen(...)
2.0 InternetConnect(...)
3.0 HttpOpenRequest(...)
4.0 HttpSendRequest(..)
4.1 Error (ERROR_INTERNET_SECURITY_CHANNEL_ERROR)
4.2 I do not know how to handle this error, so...
4.3 Raise the original exception "Secure Channel Support Error"
5.0 InternetCloseHandle(HttpOpenRequestHandle)
6.0 InternetCloseHandle(InternetConnectHandle)
7.0 InternetCloseHandle(InternetOpenHandle)
All other requests from now are just like the second one.
My questions are:
As I'm closing all the handles and doing a "totally new connection", the results between the calls should not be the same?
If not, why?
And there are a way to do an all new connection? How?
Actually, i only get a totally new connection by closing the entire application :( and starting over

The problem was caused by some kind of SSL cache, wich can be erased by executing the following code block BEFORE the request:
type
TSslEmptyCache = function (pszTargetName: LPSTR; dwFlags: DWORD): BOOL; WINAPI;
TIncrementUrlCacheHeaderData = function (nIdx: DWORD; lpdwData: LPDWORD): BOOL; WINAPI;
var
SchannelDLLHandle, WinInetHandle: HMODULE;
SslEmptyCache: TSslEmptyCache;
IncrementUrlCacheHeaderData: TIncrementUrlCacheHeaderData;
SchannelDLLHandle := LoadLibrary('schannel.dll');
WinInetHandle := LoadLibrary('wininet.dll');
if (SchannelDLLHandle > 0) and (WinInetHandle > 0) then
try
SslEmptyCache := GetProcAddress(SchannelDLLHandle,'SslEmptyCacheW');
IncrementUrlCacheHeaderData := GetProcAddress(WinInetHandle,'IncrementUrlCacheHeaderData');
if Assigned(SslEmptyCache) and Assigned(IncrementUrlCacheHeaderData) then
begin
SslEmptyCache(nil,0);
IncrementUrlCacheHeaderData(14,#buffer);
end;
finally
FreeLibrary(SchannelDLLHandle);
FreeLibrary(WinInetHandle);
end;
For more information, read this article.

Related

KMDF 1.11 Get process that initiates request

I'm writing a driver that listens for requests on specific devices by registering for EvtIoDeviceControl.
DF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&IoCallbacks, WdfIoQueueDispatchParallel);
IoCallbacks.PowerManaged = WdfFalse;
IoCallbacks.EvtIoDeviceControl = EvtIoDeviceControlCallback;
On Windows 10 (KMDF 1.21), I can use WdfRequestGetRequestorProcessId to get the process ID of the process that made the request in the EvtIoDeviceControlCallback, but I'm having trouble finding a way to do this one earlier versions of KMDF. Any insight?
you can use WdfRequestWdmGetIrp (Minimum KMDF version 1.0) and IoGetRequestorProcessId
so simply use
ULONG WdfRequestGetRequestorProcessId_1_0(WDFREQUEST Request)
{
return IoGetRequestorProcessId(WdfRequestWdmGetIrp(Request));
}

WinHttpSendRequest: 2148074273 insufficient cache

I am building a Rest client with cpprest-sdk to communicate with a web service. The problem is that every once in a while, after sending multiple successful requests (around 50), I get the exception:
WinHttpSendRequest: 2148074273 insufficient cache in function
Or sometimes:
ERROR_WINHTTP_SECURE_FAILURE (12175)
I tried to look for cache options in cpprest-sdk but did not find anything. Since the exceptions happens inside cpprest-sdk when I call .wait() on my task I am not sure if I can use the WINHTTP_STATUS_CALLBACK to check for more details on this error. How can I investigate deeper to find the cause of this error?
Here is my Rest request:
void MyRestClient::PostKeys(const std::string & sKek, const std::string & sKid, const std::string & sCustomerAuthenticator) {
uri_builder oBuilder(U("/keys?customerAuthenticator=") + to_string_t(sCustomerAuthenticator));
oBuilder.append_query(KEK, to_string_t(sKek));
json::value oBody;
oBody[KID] = json::value::string(to_string_t(sKid));
web::http::http_request oRequest;
oRequest.set_method(methods::POST);
oRequest.set_request_uri(oBuilder.to_uri());
oRequest.set_body(oBody);
m_oCurrentTask = oClient.request(oRequest).then([this](http_response oResponse) {
OnPostResponse(oResponse);
});
}
According to https://msdn.microsoft.com/en-us/library/windows/desktop/aa383928(v=vs.85).aspx (4th bullet), Post requests should not be cached so I don't understand why I am getting the first exception. I also tried to disable Https caching as the 6th bullet in the link suggest, but that did not change anything.
Did anyone experienced something similar or have any insight as to what may be happening? Or is this a normal behavior and should I just retry my request when these exceptions happens?
Does your Web Service use TLS with Diffie-Hellman key exchange? If yes, you are probably seeing a bug in SChannel, which is the SSL implementation of Windows, see here for a confirmation. Unfortunately, the only available fix is an update of the Windows version on which your client is running to a recent build of Windows 10.

WebServiceException: Method Parameter: <foo> cannot be null. This is BP 1.1 R2211 violation

Recently I migrated my application from jboss5.1 to Glassfish 3.1.2. Despite other problems I`ve found, now I cannot pass a null parameter to my web method anymore. And it was not a problem in Jboss. What should I do? Is there a flag to allow null parameter through my web melhod.
(My application uses icefaces3.0.1 and JSF 2.0; the WS is a EJB project, also in the same server for now) tks
error:
javax.xml.ws.WebServiceException: Method Parameter: toDate cannot be null. This is BP 1.1 R2211 violation.
The whole thing did get discussed here: https://java.net/jira/browse/JAX_WS-128
JAX-WS 2.0 enforces strict Basic Profile 1.1 compliance. The following
are known cases where .NET framework does not enforce strict BP 1.1
semantics and their usage can lead to interoperability problems.
Also at Oracle: http://docs.oracle.com/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/DataBinding7.html
Not quite sure when but I think I had the same problem when migration from Tomcat 5 to 6

Has glassfish 2.1.1 a bug handling http request and handle them twice?

I'm using glassfish 2.1.1. I've watched a mysterious http/webservice-call handling. It seams an http request is handled by two different threads.
After http basic authentication the first thread is faster. Persisting some data end, but writing response fails in glassfish internal.
The second thread fails, because it tries to persist identical data and there are (unique) constrain failures. The response (the failure) of second thread was delivered to client.
I don't won't discuss the behavior with the unique constrain failure. I've improve the webservice, so it can handle this better, because it could be happen anytime, that the client send the ws call a second time.
But I think, glassfish 2.1.1 has an bug handling http request. Is there any known issue? Have I done an mistake?
[#|2010-03-22T10:40:54.150+0000|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs) ...|#]
...
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Received WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|Received WebService call to enqueue() from client 59|#]
...
[#|2010-03-22T11:18:44.267+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Successfully finished WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.329+0000|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|invocation error on ejb endpoint MyWebService at /MyWebserviceService/MyWebservice : com.sun.xml.stream.XMLStreamException2
javax.xml.ws.WebServiceException: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:111)
at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:281)
at com.sun.xml.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:320)
at com.sun.xml.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:93)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:454)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:231)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:157)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.executeServlet(CometEngine.java:616)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.handle(CometEngine.java:362)
at com.sun.enterprise.web.connector.grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:84)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:189)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:164)
at com.sun.enterprise.web.connector.grizzly.async.AsyncProcessorTask.doTask(AsyncProcessorTask.java:92)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:264)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:416)
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:109)
... 36 more
Caused by: ClientAbortException: java.nio.channels.ClosedChannelException
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:385)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:351)
at org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:176)
at com.sun.xml.stream.writers.UTF8OutputStreamWriter.flush(UTF8OutputStreamWriter.java:153)
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:414)
... 37 more
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:126)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:91)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:66)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:172)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushChannel(AsynchronousOutputBuffer.java:81)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:205)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushBuffer(AsynchronousOutputBuffer.java:114)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:183)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flush(AsynchronousOutputBuffer.java:104)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.action(DefaultProcessorTask.java:1100)
at org.apache.coyote.Response.action(Response.java:237)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:381)
... 41 more
|#]
[#|2010-03-22T11:18:44.376+0000|WARNING|sun-appserver2.1|oracle.toplink.essentials.session.file:/mygf-211/domains/mydomain/applications/j2ee-apps/myear/myjar-myPu|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|
Local Exception Stack:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.1 (Build b31g-fcs (10/19/2009))): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Eine Zeile mit doppeltem Schlüssel kann in das 'dbo.MY_TABLE'-Objekt mit dem eindeutigen 'MY_INDEX'-Index nicht eingefügt werden.
I did a quick search at https://glassfish.dev.java.net/issues/query.cgi and did not see a report that looked like a duplicate of the situation that you are encountering here... though I may have missed it.
You should probably report this issue to the GlassFish developers, via their issue tracker: https://glassfish.dev.java.net/servlets/ProjectIssues.
You may have misread the log or done something wrong in your code, but this is really hard to tell given the limited amount of info that you have given in this question... But, SO doesn't really work as an issue analysis/resolution system. The GF issue tracker is a better choice for that.

javax.microedition.xml.rpc.Operation.newInstance returns null - JSR172

I am using the Sun Wireless Toolkit 2.5.2 to generate web services client stubs. When running the generated code, the method Operation.newInstance method always returns null. The generated code is:
Operation op = Operation.newInstance(_qname_a, _type_b, _type_c);
_prepOperation(op);
...
op is null after the call which then causes an exception in _prepOperation().
Does the JSR172 library need to be initialized before use?