I am experiencing an issue using springfox-swagger2 v2.2.0 related to the request padding port 80 for a HTTP URL.
Is there anyway to disable the generation of the port or set the port to 443 programmatically based on a Spring Profile?
Generated CURL:
curl -X GET --header "Accept: application/json" "https://test.com:80/api/users/search"
Hit the same issue, but rather than upgrade the spring framework libraries as per #Akshay answer (thanks for pointing out the Swagger2Controller.class), I added the following property to my application-dev.yml file (replace hostname with your host).
springfox.documentation.swagger.v2.host: hostName:443
I had the same issue. It is because Swagger uses a class from Spring Framework which is adding the port 80 to the host property in the /v2/api-docs json response (Check Swagger2Controller.class). I had this issue with spring framework version 4.1.4.Release. Upgrading to latest version 4.3.2.Release fixed it.
Related
I am running a basic Quarkus application on Google Cloud Run.
The default settings use HTTP 1.1 between Cloud Run and the backend container. If I enable http2 then CORS fails because the Access-Control-Allow-Origin header is mangled and returns the origin and the wildcard together and so is rejected by the browser.
For example when testing my app using the online Swagger UI the response is: access-control-allow-origin: https://petstore.swagger.io,*
Testing my app locally with curl and h2c does not show the problem. Therefore it seems that Google Cloud Run is doing some mangling of this header.
Is there some config I can set to stop this from happening?
I managed to track down the underlying problem in the framework that I was using.
The bug was that the framework was returning duplicate headers. For example:
access-control-allow-origin: *
access-control-allow-origin: https://petstore.swagger.io
There appears to be some weird behaviour in that cloud run had merged these into one header and then had concatenated the values.
When I tried to access jenkins using localhost:8080/jenkins I get the following error.
HTTP ERROR 404
Problem accessing /jenkins/. Reason:
Not Found
How to solve this?
Check your webserver which is running, if you use apache turn on the apache server by going to right path
Check this out, Apache web server to route HTTP and HTTPS traffic to Jenkins. This helps too
1.use URLs that lack the pesky port tag
2.receive external port 80 or 443 traffic
I use VisualStudio v14, recently upgraded to 7.4.1 via the NuGet package manager and Umbraco is now returning a server error page "Server Error in '/' Application" - replying with a 404 for "/umbraco/oauth/token" when I make token requests. The error also states, A public action method 'oauth' was not found on controller 'Umbraco.Web.Editors.BackOfficeController'.
I had the base Umbraco RestApi configuration working just fine in my previous installation of 7.3.8.
I have uninstalled and reinstalled the Umbraco RestApi and IdentityExtensions, validated my configurations in both Web.config and UmbracoStandardOwinStartup.cs, rebuilt my site and still getting a 404 server error. I have also validated that my UrlRewriting.config is not interfering with the request
Here is the token request I use:
curl -X POST -H "Accept: application/json" -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'grant_type=password&username=admin&password=pwd' http://localhost:12345/umbraco/oauth/token
Does anyone have any suggestions how I can debug, or better yet a solution for me?
Token authorization using the /umbraco/oauth/token service path requires a HTTPS protocol. Even though Production and/or enterprise managed servers have SSL properly configured, our PDEs seldom are.
Here's what I did to enable SSL in my Visual Studio 2015 .NET 4.5.2 web site project for my Umbraco instance.
In the *.csproj file find the node: <IISExpressSSLPort /> and change it to: <IISExpressSSLPort>44300</IISExpressSSLPort> FYI - the port number must be between 44300 and 44399 and make sure these ports are open on your PDE. Visual Studio will prompt you to make some determinations about it's behavior towards this new SSL configuration and future SSL configurations, so those determinations are up to you.
So here's a working request for a token from the localhost:
curl -X POST -H "Accept: application/json" -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'grant_type=password&username=######&password=******' -k https://localhost:44300/umbraco/oauth/token
Notice the -k flag.
Because I opted to install a local SSL generated by VS, the verification by curl fails, so the -k flag is used to disable the verification for the current request.
I hope this helps anyone who stumbles upon this thread! Good luck!
On Tika's website it says (concerning tika-app-1.2.jar) it can be used in server mode. Does anyone know how to send documents and receive parsed text from this server once it is running?
Tika supports two "server" modes. The simpler and original is the --server flag of Tika-App. The more functional, but also more recent is the JAX-RS JSR-311 server component, which is an additional jar.
The Tika-App Network Server is very simple to use. Simply start Tika-App with the --server flag, and a --port ### flag telling it what port to listen on. Then, connect to that port and send it a single file. You'll get back the html version. NetCat works well for this, something like java -jar tika-app.jar --server --port 12345 followed by nc 127.0.0.1 12345 < MyFileToExtract will get you back the html
The JAX-RS JSR-311 server component supports a few different urls, for things like metadata, plain text etc. You start the server with java -jar tika-server.jar, then do HTTP put calls to the appropriate url with your input document and you'll get the resource back. There are loads of details and examples (including using curl for testing) on the wiki page
The Tika App Network Server is fairly simple, only supports one mode (extract to HTML), and is generally used for testing / demos / prototyping / etc. The Tika JAXRS Server is a fully RESTful service which talks HTTP, and exposes a wide range of Tika's modes. It's the generally recommended way these days to interface with Tika over the network, and/or from non-Java stacks.
Just adding to #Gagravarr's great answer.
When talking about Tika in server mode, it is important to differentiate between two versions which can otherwise cause confusion:
tika-app.jar has the --server --port 9998 options to start a simple server
tika-server.jar is a separate component using JAX-RS
The first option only provides text extraction and returns the content as HTML. Most likely, what you really want is the second option, which is a RESTful service exposing many more of Tika's features.
You can simply download the tika-server.jar from the Tika project site. Start the server using
java -jar tika-server-x.x.jar -h 0.0.0.0
The -h 0.0.0.0 (host) option makes the server listen for any incoming requests, otherwise without it it would only listen for requests from localhost. You can also add the -p option to change the port, otherwise it defaults to 9998.
Then, once the server has started you can simply access it using your browser. It will list all available endpoints.
Finally to extract meta data from a file you can use cURL like this:
curl -T testWORD.doc http://example.com:9998/meta
Returns the meta data as key/value pairs one per line. You can also have Tika return the results as JSON by adding the proper accept header:
curl -H "Accept: application/json" -T testWORD.doc http://example.com:9998/meta
[Update 2015-01-19] Previously the comment said that tika-server.jar is not available as download. Fixed that since it actually does exist as a binary download.
To enhance Gagravarr perfect answer:
If your document is got from a WEB server => curl -u
"http://myserver-domain/*path-to-doc*/doc-name.extension" | nc
127.0.0.1 12345
And it is even better if the document is protected by password => curl -u
login:*password*
"http://myserver-domain/*path-to-doc*/doc-name.extension" | nc
127.0.0.1 12345
I have setup a proxy in the build file which was working perfectly on
my mac at work. But on my Ubuntu 11.04 laptop at home the proxy seems
to never return a valid response (checking with SC.ok(response)).
I have checked by curling the url:
curl -G http://localhost:4020/api/client
Output:
[{"id":"1","title":"Test","status":"1","created":"2011-07-03 07:36:44","updated":"2011-07-03 07:36:44","brands":null},
{"id":"2","title":"Arla","status":"1","created":"2011-07-03 07:43:53","updated":"2011-07-03 07:43:53","brands":null}]
Anyone got any ideas?
Thanks
Mark
I have opened an issue similar to this one. It seems that the Thin web server can't handle gzipped content from an upstream server.
If you can disable gzip on the remote server and please upvote the issue on github so that it has better chances of getting fixed.
If You are using Apache at home check Your log files (while running the app):
tail -20f /var/log/apache2/error.log
You might get this error:
Client sent malformed Host header
This is because the Host header (more precise the port) is different than Apaches standard localhost:80.