Develop Reference

CORS not working with zuul enabled gateway and swagger

I am facing strange issue while setting up cors with my swagger gateway and operating on the zuul mechanism gateway has list of microservices. on the click of it will redirect to specific service swagger doc and when I using swagger "Try it out" functionality.
This is how swagger gateway list looks like
problem is that "Try it out" calling option method call to check cross origin operation and failing with 401.
For ex.
This is my swagger gateway url
abc.com/replica-stock/swagger-ui.html
and zuul converts it to following one
replica-stock.com/swagger-ui.html
and for the "Try it out" api check the URL is like this
xyz.com/api/v1/getStock
and I am getting following error in browser console
Access to fetch at 'xyz.com/api/v1/getStock' from origin 'abc.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
and this is my request and response headers look like
Request header
:method: OPTIONS
:path: /replica-stock/api/v1/replicaStocks/13?partCode=1234&usageCode=01
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-IN,en-US;q=0.9,en-GB;q=0.8,en;q=0.7
access-control-request-headers: authorization
access-control-request-method: GET
origin: abc.com
referer: abc.com/replica-stock/swagger-ui.html
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
Response headers
access-control-allow-credentials: true
access-control-allow-headers: authorization
access-control-allow-methods: GET
access-control-allow-origin: abc.com
allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
content-length: 0
content-type: application/json;charset=ISO-8859-1
date: Mon, 17 Aug 2020 06:16:20 GMT
status: 401
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
x-vcap-request-id: 2b52f4f7-085f-449e-5429-ffbd830cd5db
Can someone help me where I have to fix this cors issue ?

Java http request for django rest framework service throws http 406 exception

I hava a django rest framework web service that works fine with httpie and firefox: when I request with httpie I have a json formatted answer and when I request with firefox an html formatted one (httpie is a http client).
Now I'm building java API to communicate with services. I'm using URL class to perform requests.
I can receive html-formatted answers from the server if I don't override the content-type property. So I looked how httpie overrides this property and did the same:
connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded; charset=utf-8");
connection.setRequestProperty("Accept", "*\\*");
Now the communication end with Http 406 error, which means that client can't accept the answer.
If I use only the content-type property I have no error but still the html-formatted answer
Does anyone know how to solve it?
EDIT (adding requests' header):
httpie:
GET /match/39.3280114/16.241917599999965/0/5/ HTTP/1.1
Host: 127.0.0.1:8001
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: /
User-Agent: HTTPie/0.9.3
java-API
GET /match/39.3280114/16.241917599999965/0/5/ HTTP/1.1
Host: 127.0.0.1:8001
Accept-Encoding: gzip, deflate
Accept: **
User-Agent: Java-API
Solved: I was using the wrong slash for Accept property

Your Accept header is malformed. It should be:
Accept: */*
See RFC 7231 § 5.3.2.
However, */* means “any media type.” If you actually want a specific media type (JSON), you should request it:
Accept: application/json

Http keep-alive protocol "Connection: close" from client but no "connection" header from server

I've a problem with broken connections and I believe this is due to an incorrect behavior respect to http keepalive but I can't understand if the 'culpit' is on the client or on the server side.
I'm dealing with a scenario where the client sends and HTTP 1.1 request with:
Connection: close
and the server does NOT reply with a Connection header.
The behavior is as follows:
The client sends the request
The server sends it response
The server does NOT close the connection
The client does NOT close the connection (.1)
The client sends another request using the same connection
The server does not do anything and after 30" closes the connection
The components are as follows:
Client: Java HttpConnection (within Dell Boomi iPaaS)
Server: SAP ERP OData Webservice
According to this article: "Should a server adhere to the HTTP Connection: close header sent from a client?" the problem seems to be on the client side. However the Java HttpURLCoonnection implementation should be pretty robust (tested x64 server VM on Linux v 1.7.0_55-b13 and x64 server on Windows 7 v 1.7.0_75-b13).
Here are the complete set of headers from the 1st request from client:
GET /sap/opu/odata/SAP/ZZSALESORDER_SRV/$metadata HTTP/1.1
User-Agent: Boomi Http Transport
Authorization: Basic YmPRIVATESECRETPLEASExNg==
X-CSRF-Token: Fetch
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: some.server.behind.firewall.local:8000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Cookie: sap-usercontext=sap-client=100; SAP_SESSIONID_DEV_100=Cm7LsDSECRETSECRETSECTERFaIMak%3d
And these are the ones from the response from the server:
HTTP/1.1 200 OK
content-type: application/xml
content-length: 79750
x-csrf-token: oolTHISAGAINISASECRET3PA==
last-modified: Fri, 25 Mar 2016 17:55:35 GMT
dataserviceversion: 2.0
After the server has replied the client sends a second request using the same connection:
PUT /sap/opu/odata/SAP/ZZSALESORDER_SRV/SalesOrderItems(NumDocSap='1200001534',PosId='000020') HTTP/1.1
User-Agent: Boomi Http Transport
Content-Type: application/atom+xml
X-CSRF-Token: oolZMYSECRETPA==
Connection: close
Authorization: Basic YmPRIVATESECRETPLEASExNg==
Cache-Control: no-cache
Pragma: no-cache
Host: some.server.behind.firewall.local:8000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 406
Cookie: sap-usercontext=sap-client=100; SAP_SESSIONID_DEV_100=Cm7PRETTYPRIVATESECRETak%3d
and the server does not reply and closed the connection abruptly after 30".
The problem can be completely resolved setting the JVM flag
http.keepAlive=false
on the java client side (Boomi) but this seems more of a workaround then a solution.
Can someone please explain:
is there an HTTP protocol violation on client or server side?
can this be fixed by sending different headers?

Java HttpServer Basic Authentication problems

I have an implementation of Java's HttpServer that I use for testing its pretty basic and means I can adjust what is served up to the client on the fly. My code is using apache http client.
I would like to test some authentication using this Implementation but i'm having some issues. My problem is that my code never authenticates, the initial request is sent and the server responds with 401 but the http client never responds. It goes through the list of authentication types but never chooses BASIC
If i connect to the same url using my browser I am prompted and when i submit credentials it logs in. If i change my code so the code attempts to log into some other server it is successful, so i know that both ends work!
I have wiresharked the connection on the client and server side and the differences I can see are:
when the connection is successful the subsequent request is sent as a POST not a GET.
when my server responds the authentication header is Www not WWW (as it is when it works)
EDIT:
Looking through the http code the case sensitivity shouldnt be causing any problems. The first response is the one that fails and the second is the one that works:
Fails
GET /testing HTTP/1.1
Host: 192.168.30.65:8000
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.0-beta1 (java 1.5)
HTTP/1.1 401 Unauthorized
Content-length: 0
Www-authenticate: Basic realm="myRealm"
Works
GET /svn HTTP/1.1
Host: svnserver
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.0-beta1 (java 1.5)
HTTP/1.1 401 Authorization Required
Date: Mon, 16 Apr 2012 09:51:58 GMT
Server: Apache/2.2.3 (CentOS)
WWW-Authenticate: Basic realm="Subversion Repository"
Content-Length: 475
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at svnserver Port 80</address>
</body></html>
GET /svn HTTP/1.1
Host: svnserver
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.0-beta1 (java 1.5)
Authorization: Basic YQVkd2Gm3GS6dXNjbMk5

HTTP gzip encoding with multipart message

I am trying to send a gziped multipart POST to a Tomcat server from a Java application using Jersey. When the multipart request is not compressed, it works perfectly fine. Other types of compressed POSTS work fine, such as sending a single entity XML. I (believe) posting compressed data isn't an HTTP standard, but it does seem Tomcat supports it to some degree.
a working uncompressed multipart post:
POST /myApp/rest/data HTTP/1.1
Content-Type: multipart/mixed; boundary=Boundary_1_23237284_1331130438482
Cookie: JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXX;Version=1;Path=/myApp/
MIME-Version: 1.0
User-Agent: Java/1.6.0_26
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Transfer-Encoding: chunked
d3
--Boundary_1_23237284_1331130438482
Content-Type: application/octet-stream
Content-Disposition: form-data; filename="uploadFile.war"; modification-date="Wed, 29 Feb 2012 18:01:38 GMT"; size=25343899; name="file"
{binary data here}
--Boundary_1_25179713_1331128929019
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><myXMLEntity>stuff</myXMLEntity>
--Boundary_1_25179713_1331128929019--
When I compress it using the Jersey GZIPContentEncodingFilter() the following headers are sent, and I get back an HTTP 400 with a description of "incorrect syntax"
POST /myApp/rest/data HTTP/1.1
Content-Type: multipart/mixed
Cookie: JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;Version=1;Path=/myApp/
Accept-Encoding: gzip
Content-Encoding: gzip
User-Agent: Java/1.6.0_26
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Transfer-Encoding: chunked
{binary data here}
Is what I'm trying to do possible? Should the Content-Type actually read multipart/x-gzip? I notice that when it gets compressed, the boundary text gets left off of the Content-Type header - is this also a problem?

I ran into this same issue (or something very similar) and tracked it down to the Content-Type header missing the boundary parameter when using GZIPContentEncodingFilter. I was able to work around it by using MultiPartMediaTypes.createFormData() when setting the type of the entity I was POSTing from the Jersey client. Doing so makes sure the boundary parameter is set earlier than Jersey would automatically set it, which seems to be too late when using the GZIPContentEncodingFilter for compressing the request entity. There is an equivalent method for multipart/mixed.
I don't have an IDE handy but something similar to this:
// client is a Jersey Client object
client.resource(uri).entity(multipartFormData, MultiPartMediaTypes.createFormData()).post(ClientResponse.class);
All that said, this will still only work if your server is able to handle GZIP compressed requests.

IMO you can't do this that way, because the server and the client need to agree on how to communicate (e.g. zip compression). HTTP is designed as request/response and server can return what the client can support.
The client sends request to the saying, "Hey server, I need this resource and I support gzip, so you can return gzip if you can". :)
Imagine a situation that your client sends to the server a few megabytes in gzip, but the server doesn't support this.