adoptium api swagger page anf URLs generated for AIX

[aixtools]

Describe the bug
The feedback from the site is confusing at best.

• The generated URL's that report "TypeError: NetworkError when attempting to fetch resource (no 404 code)" work in applications
• The generated URL's that report a 404 code: Error: Not Found also give a short header block.
• So, it seems like everything you try using swagger is an error, and is quite frustrating!
  To Reproduce
  Steps to reproduce the behavior:

1. Go to https://api.adoptium.net/q/swagger-ui/#/Binary/getBinary
2. Click on 'Try it Out'
3. Fill in your choices:
   
4. Click 'Execute'
5. See error
   
   Expected behavior
   A clear and concise description of what you expected to happen.

• Something similar to the linux-x86 output
  

Screenshots
If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• OS: [e.g. Windows]
• Browser [e.g. firefox]
• Version [e.g. 97.0.1 64-bit]

Additional context
Basically, if I see this:

• it is an unsupported feature_version, e.g., 10
• implying, unsupported is better supported by swagger than supported feature_versions

[tellison]

I'm not able to reproduce the problem Michael (@aixtools). I get a 404 NotFound error as expected rather than a NetworkError which is what you noted.

Please can you retry and see if the networking error still occurs?

[johnoliver]

I think the issue is you have given a url that actually exists, so should not 404, in fact will 302 you to the binary you requested, unfortunately what probably happened is that your browser blocked the 302 redirect to github due to CORS.

[karianna]

Leaving this open in case we can figure out a CORS workaround.

[aixtools]

I don't think it is a 302 blocking - why for this site only?

a) iirc, the old swagger api redirect to the new site - and those work fine.
b) this is not a browser failing - initially - but a 'fetch' using adoptium. The display above was to make it clearer why what was being returned by the API was not working.

[netomi]

I could reproduce the problem with firefox. Debugging it on firefox shows a CORS Missing Allow origin error.
Also looking at the request being made to github.com, there are no cors request headers present, although it is configured in the application.properties file.

Looking at the configuration at

api.adoptium.net/adoptium-frontend-parent/adoptium-api-v3-frontend/src/main/resources/application.properties

Line 6 in 037533b

quarkus.http.cors.methods=*

the problem might be with the use of wildcards:

quarkus.http.cors=true
quarkus.http.cors.origins=*
quarkus.http.cors.methods=*
quarkus.http.cors.headers=*

quarkus.http.cors.methods does not support a '*' wildcard afaict from the source code:

https://github.com/quarkusio/quarkus/blob/4746a6925eea344c6ee2ea80cf5ee1e1c8801c4b/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/cors/CORSFilter.java#L42

so the configuration would specify that for a '*' request, the cors headers are added, but a request method like that does not exist ofc. I would suggest to explicitly set this to 'GET, OPTIONS', or leave that setting empy which should default to all afaict.

Link to the quarkus documentation: https://quarkus.io/guides/http-reference#cors-filter

[xavierfacq]

I just add some details to explain that the problem is that the browser doesn't allow to follow the 307 redirection to GitHub.

swagger-ui/#/Binary/getBinary:1 Access to fetch at 'https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u392-b08/OpenJDK8U-jdk_ppc64_aix_hotspot_8u392b08.tar.gz' 
(redirected from 'https://api.adoptium.net/v3/binary/latest/8/ga/aix/ppc64/jdk/hotspot/normal/eclipse?project=jdk')
 from origin 'https://api.adoptium.net' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
github.com/adoptium/temurin8-binaries/releases/download/jdk8u392-b08/OpenJDK8U-jdk_ppc64_aix_hotspot_8u392b08.tar.gz:1

[netomi]

ty for chiming in. I tested locally to update the cors-filter by explicitly specifying the methods, but it did not change a thing, so the request did not include a Access-Control-Allow-Origin header that would be required. I had the same problem for other things that are based on swaggerui (httpbin for example), so I guess the problem is in the way the swaggerui code does the request. I am not an expert in javascript so cant really help in fixing that, but it would be something that would be worthwhile to fix upstream imho.