Priority REST: No “Access-Control-Allow-Origin” header in response - priority-web-sdk

No "Access-Control-Allow-Origin" header in response.
It prohibits any requests from the client.
Issue can be "solved" by rise proxy server, but it is not correct solution.
Is this issue are common for whole Priority REST ?
Can REST server return "*Access-Control-Allow-Origin: **" ?
Or how we can specify allowed domain list ?

The definition comes from the server where the system is stored.
If you have access to the server, you can try to set it up there.

If you are hosted on Priority-Software servers then I suggest you contact them
and ask them to add your domain to the Access-Control-Allow-Origin list.


Http Request - Bypass DNS [.Net]

Is it possible (and if yes, how) to bypass DNS when doing a HTTP request ?
I want to hit directly a front-end with an HTTP request, without getting through NLB but with the correct host header.
As I have the IP of my server, I just need to bypass the DNS.
I tried to use WebRequest, replacing the URL with the IP and setting the Host header, but this header is protected.
How can I do that ? Do I need to create the HTTP request myself ?
Note: editing host file is not an option
At the time this question was asked this was not possible to do with the WebRequest class. However following a Microsoft Connect issue raised as a result of this question, Microsoft Added the Host property to the HttpWebRequest class in .Net version 4.0. As such if you are using .net 4.0 or later you can achieve what you want with this code.
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("");
Request.Host = ""
Prior to version 4 of .Net the only real option is to open a Socket and do the HTTP request yourself or find a 3rd Party component that has more functionality.
I manage to do what I need setting the proxy to the IP address of the remote server :
request.Proxy = new WebProxy(ip.ToString());
It doesn't work in all scenarios, but it did in my case.
I had a similar problem myself, but managed to get around it using sockets (As mentioned by Martin Brown. Here is my answer:
You can use my solution for this problem, it posted here :
How to set custom "Host" header in HttpWebRequest?
This can help you to edit host header, and avoid to using proxy workaround.

When should I really set “Access-Control-Allow-Credentials” to “true” in my response headers?

MDN says, when the credentials like cookies, authorisation header or TLS client certificates has to be exchanged between sites Access-Control-Allow-Crendentials has to be set to true.
Consider two sites A - and another one is B- Now I have to make a http Get request from A to B. When I request B from A I am getting,
"No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin '' is therefore not allowed
So, I'm adding the following response headers in B
response.setHeader("Access-Control-Allow-Origin", request.getHeader("origin"));
This resolves the same origin error and I'm able to request to B. When and why should I set
response.setHeader("Access-Control-Allow-Credentials", "true");
When I googled to resolve this same-origin error, most of them recommended using both headers. I'm not clear about using the second one Access-Control-Allow-Credentials.
When should I use both?
Why should I set Access-Control-Allow-Origin to origin obtained from request header rather than wildcard *?
Please quote me an example to understand it better.
Allow-Credentials would be needed if you want the request to also be able to send cookies. If you needed to authorize the incoming request, based off a session ID cookie would be a common reason.
Setting a wildcard allows any site to make requests to your endpoint. Setting allow to origin is common if the request matches a whitelist you've defined. Some browsers will cache the allow response, and if you requested the same content from another domain as well, this could cause the request to be denied.
Why should I set Access-Control-Allow-Origin to origin obtained from request header rather than wildcard *?
You shouldn’t unless you’re very certain what you’re doing.
It’s actually safe to do if:
The resource for which you’re setting the response headers that way is a public site or API endpoint intended to be accessible by everyone, and
You’re just not setting cookies that could enable an attacker to get access to sensitive information or confidential data.
For example, if your server code is just setting cookies just for the purpose of saving application state or session state as a convenience to your users, then there’s no risk in taking the value of the Origin request header and reflecting/echoing it back in the Access-Control-Allow-Origin value while also sending the Access-Control-Allow-Credentials: true response header.
On the other hand, if the cookies you’re setting expose sensitive information or confidential data, then unless you’re really certain you have things otherwise locked down (somehow…) you really want to avoid reflecting the Origin back in the Access-Control-Allow-Origin value (without checking it on the server side) while also sending Access-Control-Allow-Credentials: true.
If you do that, you’re potentially exposing sensitive information or confidential data in way that could allow malicious attackers to get to it. For an explanation of the risks, read some of the following:
And if the resource you’re sending the CORS headers for is not a public site or API endpoint intended to be accessible by everyone but is instead inside an intranet or otherwise behind some IP-address-restricted firewall, then you definitely really want to avoid combining Access-Control-Allow-Origin-reflects-Origin and Access-Control-Allow-Credentials: true. (In the intranet case you almost always want to only be allowing specific hardcoded/whitelisted origins.)
Setting Access-Control-Allow-Credentials: true actually has two effects:
Causes the browser to actually allow your frontend JavaScript code to access the response if credentials are included
Causes any Set-Cookie response header to actually have the effect of setting a cookie (the Set-Cookie response header is otherwise ignored)
Those effects combine with the effect that setting XMLHttpRequest.withCredentials or credentials: 'include' (Fetch API) have of causing credentials (HTTP cookies, TLS client certificates, and authentication entries) to actually be included as part of the request. in the Fetch spec has a nice example

Disable cache sharing among websites

Is there a way to tell the browser not to share a cached resource among websites?
I want to give websites a link to some JavaScript on my server and I want to make the response be different for each domain using the Referer header as check.
The response which will be cached should be available to the domain that requested it and when the end users visit another site that uses the script link, another request should be made.
I don't know whether I understand your question.
Does your scenario like: and use the same script called "", but you don't want to share the cached script with
This is under the control of's web server.
So if the cached resource's origin server( want to implement the feature as you said, it may use the Vary response header. Vary Header define the secondary key of cache.
Maybe "Vary: Origin" but only work for CORS
Maybe "Vary: referer" but referer contains url path
It still doesn't solve your problem but I hope it helps.
see MDN HTTP Cache Doc and [RFC 7234 Section 4.1]

HTTP GET request with locale

Sometimes when I navigate to a website, the GET request is:
GET /se/ HTTP/1.1
How is the locale being added instead of just the root? From what I see it is the first request I send to the server. Is my browser adding this in? If so, how does it know to add it for some sites and not others?
I guess the server redirected your request to '/se/' based on the your preferred language that is detected from Accept-Language header in your request.
The server can have whatever rules it likes to do this. Generally, as #npcode mentioned, Accept-Language should be used, but it's possible that the website in question is directing you there based on ip geocoding rules. If you connect via a proxy in another country, does it still happen?

Cross Origin Resource Sharing with Credentials

I have a common authentication form across multiple subdomains (,, and The login form must submit this data to irrespective of where it is shown, so I thought of using CORS, but this:
does not work
So I thought of doing the next thing, and checking the Origin header manually on server side, and allowing a Access-Control-Allow-Origin: * so that requests might be made, but unfortunately, this crops up in the MDN
Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding.
Is there any way to make my request work across multiple domains, and still send credentials using CORS ?
Two thoughts:
1) are you also including the "Access-Control-Allow-Credentials: true" header? This is needed for passing cookie credentials (and the corresponding XHR client must set .withCredentials = true)
2) Have you tried the suggestion from your link and only include the origin for the current request. For example, if a request comes in with the header "Origin:", you would respond with "Access-Control-Allow-Origin:", and not a list of origins. This requires a little more work on your server side implementation.
3) One other thought, you mention that you have a single login form that must be shared by various domains. Well, if it is a standard HTML form, you can do a regular form-post across domains. You don't need to use CORS. Just set the "action" property of the form to the url you wish to post to. For example:
<form name="login" action="">
// cross domain
header("Access-Control-Allow-Origin: ".$_SERVER['HTTP_ORIGIN']);
header('Access-Control-Allow-Credentials: true');