HttpProcessor Error 520

9 views
Skip to first unread message

Mathew Tasalloti

unread,
May 28, 2022, 3:41:54 AMMay 28
to Fusio
Hi Christoph,

We are developing an internal API server using Microsoft's ASP.Net 6 environment.   We are running into a strange issue that I'm wondering if you may be able to guide me on.

Using Insomnia, when accessed directly, all of our endpoints pass and we get 200 response with the Json results expected (please see attachment).  
Without-Fusio.JPG
However, when I put these end point through Fusio using HttpProcessor I get HTTP Error 520 reported and no contents.  
Fail-with-Fusio-body.JPG
Fail-with-Fusio.JPGAlso, using CLI, I can put he curl statement in the Action and get responses successfully ... but we need to do this through HttpProcessor to be able to use our parameters and headers.

In my investigations,
- The Action, in Designer mode, is successful and shows the right response
- All the logs in our system show success
- Apache2/PHP logs don't show any errors, nor any errors in the Fusio logs

Sounds like an issue in the Route section but any suggestions / ideas about what is going on or how to track it down?  many thanks for any insights.

Best Regards,
Mathew 

Christoph Kappestein

unread,
May 28, 2022, 5:06:42 AMMay 28
to Fusio
Hi Mathew,

ok, it seem that the 520 Status-Code is Cloud-Flare specific so I assume that it gets returned by Cloud-Flare since Fusio does not return such a Status-Code. For Cloud-Flare this means "520 Web Server Returned an Unknown Error" could you invoke the route directly without Cloud-Flare so that we can see the actual response (headers/body) of Fusio?

best regards
Christoph

Mathew Tasalloti

unread,
May 28, 2022, 4:54:56 PMMay 28
to Fusio
Hi Christoph,

Thanks so much for the second set of eyes on this.   Finally ended up getting this to work this morning - here is what I ended up having to do:

1) The new Microsoft Kestrel server for ASP.Net 6 defaults to listening for "localhost" only.  So even though we have Fusio and the upstream server on the same machine, things weren't somehow linking up.
           You just have to start the Kestrel server with the "dotnet <app> --urls "0.0.0.0:3000" command to get going there - likely led to the cloudflare message
2) After this some of our calls were still not working, but some were.   Out of desperation and dumb luck, ended up setting the HTTP version to 1.0 in the Action and viola !!!  will just need to remember to set that as we go along.

Looks like we are now going end to end with an upstream Kestrel server as well.

Thanks again for your suggestion to get Cloudflare out of the way!

Cheers and have a great weekend !!
Mathew
Reply all
Reply to author
Forward
0 new messages