Errors in PhotoHunt sample app - google-plus

I followed the following documentation to see demo for the PhotoHunt app.
https://developers.google.com/+/photohunt/java
When I run the application, I get the following in the web-browser
HTTP ERROR: 503
Problem accessing /. Reason:
SERVICE_UNAVAILABLE
Powered by Jetty://
Did I miss something?

You have to generate getters and setters for the variables declared. Could run the application when these are generated.

Related

WebApi Deployed to IIS: Error: Exceeded maxRedirects. Probably stuck in a redirect loop

I have two Api's that are deployed and running fine in my local IIS. They deploy fine and swagger works but executing any method returns a TypeError: Failed to fetch Error. Then I run the same GET in Postman and it throws Error: Exceeded maxRedirects. Probably stuck in a redirect loop
Has anyone seen this before? We are going through an Azure App Gateway...could that be a problem?
-Ken
The Azure Gateway turned out to be the problem. I commented out the app.UseHttpsRedirection() and the problems went away.

Stencil not working with a 500 server error

Using stencil 3.0.3, node 12.21 cornerstone theme was working and suddenly stopped with a weird server error:
Debug: internal, implementation, error
Error: The BigCommerce server responded with a 500 error
at Object.internals.getResponse (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/server/plugins/renderer/renderer.module.js:128:15)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async internals.implementation (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/server/plugins/renderer/renderer.module.js:39:20)
at async module.exports.internals.Manager.execute (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/toolkit.js:45:28)
at async Object.internals.handler (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/handler.js:46:20)
at async exports.execute (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/handler.js:31:20)
at async Request._lifecycle (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/request.js:312:32)
at async Request._execute (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/request.js:221:9)
I have tried to re-install big commerce stencil, clean build and still get the same error.... at this point I have no idea what could be causing this issue.
Importantly, there was no code changes in between the day where everything was working and the day where it stopped.
Are you using CloudFlare for a CDN? I've ran into this issue and have had to edit my hosts file
I add the following 3 lines.
The first one is for the Store Domain, i.e. if you have MyShoeStore.com
The second 2 contain the auto-generated store-hash for a BigCommerce store that should be visible in your URL bar if you are on the BigCommerce control panel (Logged into the admin view - that's the easiest way to get it, there are some others)
35.186.223.98 mystoredomain.com
35.186.223.98 store-abcdefg[store-hash].mybigcommerce.com
35.186.223.98 www.store-abcdefg[store-hash].mybigcommerce.com
For some reason, Stencil-CLI gets thrown for a loop when trying to connect to a BigCommerce store that is running behind CloudFlare CDN. This has caused 500 errors in the Stencil-CLI, and a failure to render, during local development, but the store is able to be uploaded and hosted in production without a problem.
I'm not sure if this is the actual issue that you had which caused your 500 error, (It can be due to an error in the syntax of one of the HandleBars templates, but usually Stencil-CLI will output an informative error for that reason.)
The other situation I have seen this in is if you are trying to run Cornerstone on a very old BigCommerce store which is still running their old template framework (Blueprint) - in that situation, certain pages will 500, but others will work.
This may be helpful for others who are running into this.
I installed a proxy tool to capture traffic between stencil and BigCommerce in order to perhaps find more details on this error.
Unfortunately, as soon as I did that, the site worked again...

The CGI application did not return a valid set of HTTP errors. 502.3 - Bad Gateway: Forwarder Connection Error (ARR) on Azure ASP.NET Core App

All of a sudden we are seeing this random error / exception in our web application.
Failed to load resource: the server responded with a status of 502 (Bad Gateway).
In the Log Stream, we are seeing the following details, with specific error code as 502.3 - Bad Gateway: Forwarder Connection Error (ARR).
Also, sometimes in the browser itself we see "The CGI application did not return a valid set of HTTP errors." getting displayed.
Most of the searches for these error codes refer to "IIS / Proxy Server" configuration. But, we haven't changed any such settings.
The error happens very randomly and not specific to any user action/function. Same functionality works first and on second execution immediately after first one throws this error.
How to figure out what is causing this and how to fix?
I google this question, because the program was normal at the beginning, and the subsequent 502.3 error. After I checked the information on the Internet, I feel that it can only give us an inspiration, and it cannot solve your problem immediately.
So my suggestion is that first you browse post1 and post2 I provided.
Next, proceed to Troubleshoot according to the steps of the official documentation. Specific errors require specific analysis.

Can't disable WSGIErrorOverride

I am backing a web app with a Flask API that returns custom error codes. The API runs through Apache and the WSGI module, in daemon mode.
I included a WSGIErrorOverride Off instruction in the Apache conf file for the API (which is supposed to be the default but I included it anyway).
Yet anytime my Flask app returns a custom error code (they work when I run the app using the built-in server), Apache sends an error 500. How can I prevent that?
Thanks to comments by duskwuff and Graham Dumpleton, I found that the problem doesn't come from Apache WSGI but from my Flask app.
More precisely, I was using the Flask-RESTful package, which is in charge, among other things, of transforming my views' return values into actual responses.
When those views are decorated (here with an equivalent of #login_required), those decorators are called by the Flask-RESTful package itself, and when an exception is thrown, something goes wrong.
For some reason, my app returns the custom error when I run the built-in server and an error 500 when I run it over Apache. Not quite sure why yet, I'm guessing Flask-RESTful is doing something that is not WSGI-compliant. I was on the verge of dropping it anyway for other reasons, so I'm OK with this solution.
Update: it looks like the problem does indeed come from Flask-RESTful: https://github.com/flask-restful/flask-restful/issues/372

IBM Worklight 6.0 - Error accessing Worklight Server

I am trying to run this sample code provided by IBM, but when I run it I get this error:
So I understand the HTTP 403, but where should I make neccesary changes to make this thing work? I saw this SO question: Jetty returning 403 Forbidden but no luck; I could not find that parameter anywhere in any file in my project.
Sometime earlier I got this error too Error 404: SRVE0190E: File not found: /
So lame, I had to deploy the adapter first then I deployed the native api, made neccessary changes voila I am good to go.