I have HTTP Version set to 2.0, but App Service is acting like it is not.
I'm using https://tools.keycdn.com/http2-test to test and it says Negative! <site> does not support HTTP/2.0.
Chrome is also using HTTP/1.1.
It looks like this is affecting all apps in the App Service Plan. I have 2 currently and neither have working HTTP/2. I added a third and it doesn't support HTTP/2 either. I have HTTPS setup on both apps and my requests are using HTTPS.
I've tried all sorts of combinations of changing the setting and restarting. I've tried stopping both apps and then restarting them.
I contacted Azure support and they found an issue with the server my app service was hosted on. They were able to fix the issue and it is working now.
I test in my site and get the same error message with you. However after waiting for serveral minutes, it will turn to HTTP/2.
As you have tested, go to App Service's Application Settings and set the HTTP version to 2.0. It may caused by the response delay.
If you want to ensure it, as Zahid said, you could refer to this blog to check if the http20Enable attibute value is true.
Azure is just starting releasing the full HTTP/2 support.
HTTP/2 is supported as HTTP Server on AppService but the ILB (Reverse-proxy) router doesn't support on the client side the HTTP/2.
So the HTTP/2 is not available end to end because of the internal reverse-proxy (ARR) but they are migration on YARP Project with support HTTP/2 and gRPC.
Related
My client has a functionality in the App where it converts an audio file into text. For this, I am using the Google Cloud Speech to text API. The client has a VM setup where there is no internet connection available, and all the network traffic should go through a proxy if it needs to connect to the internet. The SpeechToText API calls don’t go via the proxy, but directly hit the firewall, which in turns blocks it and the translation fails.
I looked for ways for using global proxies in the APP, which didn’t work as these calls are gRPC based and not REST based. Looked on gRPC code as well for the proxy settings and used one of the environment variables that they provide for the same, but even that didn’t work.
I also tried to check in the Google Speech To Text client libraries if they provide proxy related settings, but even there is no solution for that.
The Google Cloud API calls use gRPC and gRPC protocol is using HTTP/2 which doesn’t seem to provide proxy based control.
I already tried to follow the steps in the instructions, however it's still not working to send the traffic via the proxy.
Any ideas what else I can do?
https://medium.com/google-cloud/accessing-google-cloud-apis-though-a-proxy-fe46658b5f2a
https://developers.google.com/gdata/articles/proxy_setup
Working with an extremely simple proxy service configured on the new 1.0.0 Micro Integrator by WSO2. I use the Integration Studio and it's buildin intergator to run and test the functionality. It seems however that for some reason I cannot call my proxy service.
I can clearly see my changes are reflected as it boots up and the following line appears:
ProxyService named 'myprox' has been deployed from file
Also, it mentions that the endpoints have been configured:
INFO {org.apache.synapse.transport.passthru.core.PassThroughListeningIOReactorManager} - Pass-through EI_INTERNAL_HTTP_INBOUND_ENDPOINT Listener started on 0.0.0.0:9201
The custom proxy service is now narrowed down to just a LOG and RESPOND mediator. Whatever URL I use, the same error keeps popping up:
WARN {org.wso2.carbon.inbound.endpoint.internal.http.api.InternalAPIDispatcher} - No Internal API found to dispatch the message
So far I have tried every type of combination I can imagine, with every one of them providing above message. The latest I tried was:
http://localhost:9201/services/myprox
I tried with and without the "/services/" subdirectory. I tried with and without HTTPS using the provided 9164 port. I also tried the variations of the 8290 and 8253 ports to no avail.
When I run this CAR file with EI 6.5.0. I can get result on the url mentioned above.
What is going on here?
It seems you are trying to call the inbound endpoint port for a proxy. The WARN message you have shown indicates that. In micro integrator the default port for proxy services is 8290. So your proxy URL should look like below.
http://localhost:8290/services/myprox
(Please note that the above mentioned port is the default one. It might change, if you started have the server with a port offset or configured differently in your settings.)
Please go through this blog for a proxy sample created and deployed into Micro Integrator from Integration Studio.
https://www.yenlo.com/blog/a-first-look-at-wso2-enterprise-integrator-6.5.0-m5-micro-integrator-and-developer-studio
I have moved an old web app from being hosted on a very old custom implementation of a web host using Cassini to .net core 2.2 hosted in IIS.
Since the old servers were a self implementation, it wasn't rejecting some requests that IIS is rejecting.
To be specific, the problem is with POST requests with no body and no Content-Length header, with a Transfer-Encoding header of "chunked". There is absolutely no reason not to use simple GET requests there, but this is the situation.
The requests are sent from an old plugin that some of the clients are using, and we can't make them upgrade it to a newer version that is sending valid GET requests. Currently IIS is rejecting the requests with a 502 code. Therefor, we need to maintain an old version of the server just for these clients.
I am looking for a way to configure IIS to forward these requests to the .net core web app despite being invalid and to handle them there (when tested on Kestrel without IIS, the results are returned as expected).
Thanks
The problem was with IIS that acted as a reverse proxy since I used out of process hosting. Once I switched to in process hosting the request went directly to the server and the problem was solved.
https://weblog.west-wind.com/posts/2019/Mar/16/ASPNET-Core-Hosting-on-IIS-with-ASPNET-Core-22
I'm developing a simple app using WinJS for Windows 8 and 10. The app makes an Http request using Winjs.xhr.
I developed Web API hosted on a server with CORS enabled into that. Now, when I install my Win app in development machine (where API(s) are hosted), Win App is able to download the data.
On remote computer it fails. It executes error code block and returns readyState=4, status=0.
See detail description of problem I'm facing here
Finally Solved after spending my 3 days behind this searching everywhere.
I have been using http://192.168.4.134:9084/.... URL for sending the request. Initially, I had set app capability to Internet(client) and Internet(client & server). Later while rethinking I realized that since it's routed through network, I may also require Private Network (Client & Server) to be checked marked.
for now this has solved the problem, and created a question that "Do I need to check mark it when I will publish it for store?"
Another off topic question, How to sideload this app in all computers at once assuming that all those PCs are connected with single AD server under one domain?
I'm having fits accomplishing something and after scouring google & SO, throwing my hands up after a few days. Trying to do something that I think is pretty common: debug / examine all HTTP traffic while developing a node.js app.
In Windows it is as simple as firing up Fiddler and I can see all HTTP & HTTPS traffic from all processes. But I've switched platforms over to OSX and trying to make the same work.
I've tried using Charles & MITMPROXY, but all I'm seeing is the traffic to, with the response, my node.js app. My node.js app is calling external services, some using the popular request package (which I have seen how to set that up) but also using other packages, like azure-storage. What's troubling me is I can't get any of the debugging proxies to show me at the azure-storage package is sending / receiving to the endpoints they are calling.
Conceptually I think I get it... I have to tell these different things (like node.js, request & azure-storage) to go through the proxy each of these tools uses... but how can you do that without modifying their source? Can't, like how Fiddler works on Windows, you do something to "all traffic goes through this proxy"?
I'd use Fiddler on OSX but it is currently not working with no ETA in sight after talking to Telerik.
So the problem I was having is what I thought... in my specific instance the module that I was using to access Azure storage was not using the default proxy. I found a package (**global-tunnel that hijacked everything that used the request package to control it going through a proxy. Now I saw stuff show up in the HTTP debuggers I was using.
The problem now is when I am trying to reach an HTTPS endpoint... using something like Charles, it used it's own SSL cert which wasn't trusted by Azure so the connections were refused. Back to the drawing board...