Breeze always 404 - http-status-code-404

I built a oData-Service which works well.
Now I want to query them with Breeze but I always get an 404 error.
In Fiddler I see first a 200 with empty Body and then follows the 404 with "No HTTP resource was found that matches the request URI".
But running in a normal browser the odata Service delivers the right data.
I debug it and set a breakpoint on the Server to see if the service is called correctly. After sending the request the breakpoint shows that the Service is called. But parallel to the break breeze calls the fail-method of
manager.executeQuery(query)
.then(querySucceeded)
.fail(queryFailed);
and e.message is empty.
Any idea??? :-/
Next entry...
I deactivate CORS and now I get the 404 immediately.
Here is the request:
OPTIONS xxx:8080/myDataService/odata/Person?$select=Name HTTP/1.1
Host: xxx:8080
Connection: keep-alive
Access-Control-Request-Method: GET
Origin:localhost:61244
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Access-Control-Request-Headers: dataserviceversion, accept
Accept: /
Referer: http://localhost:61244/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
and here the answer:
HTTP/1.1 404 Not Found
Content-Length: 178
Content-Type: application/json; odata.metadata=minimal
Server: Microsoft-HTTPAPI/2.0
OData-Version: 4.0
Date: Mon, 19 Jan 2015 12:11:48 GMT
{
"error":{
"code":"","message":"No HTTP resource was found that matches the request URI xxx:8080/myDataService/odata/Person?$select=Name'."
}
}

No surprise that the OPTION request passes; you've probably got the server set to say "OK" to every request ... and that's just fine for now.
The rejection has to do with the address of your GET request: xxx:8080/myDataService/odata/Person. Are you sure that's the right endpoint? The path is usually plural (Persons).
It's easy enough to just paste that url into a browser address bar and see what it does.

Related

OpenWeather API React Request Header Fields Too Large 431

I have been trying to use the following code using React fetch to get a response from the OpenWeather API:
fetch('api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890')
.then(response => response.text())
.then(data => {
console.log(data)
When I skip react and just copy the url (api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890) into the browser I get a totally valid response. (For example ) When I use the fetch code in my React application, however, I get the following error:
Request URL: http://localhost:3000/api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890
Request Method: GET
Status Code: 431 Request Header Fields Too Large
Remote Address: 127.0.0.1:3000
Referrer Policy: no-referrer-when-downgrade
I am running my react application off localhost from create-react-app. Why can I access that API just fine from my browser but get an error in my app?
Extra Information
In case it is useful here is the link to sign up for a free OpenWeather API
Here is the rest of the information from the response header:
HTTP/1.1 431 Request Header Fields Too Large
x-powered-by: Express
connection: close
date: Wed, 18 Sep 2019 15:45:21 GMT
transfer-encoding: chunked
Or from the request header:
GET /api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890 HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Accept: */*
Sec-Fetch-Site: same-origin
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,es-US;q=0.8,es;q=0.7,ar-JO;q=0.6,ar;q=0.5
(My APPID is fake in all these examples, so the request won't work by just copying and pasting what I have)
It's a pretty "catchy" bug - you are missing http:// in front of your url, so:
fetch('https://api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890')
Since you've missed it, url is resolved to this (you can see it in your Network tab):
http://localhost:3000/api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890

CORS 'Access-Control-Allow-Origin' header not present issue

I'm writing the client-side of an app with ReactJS, I'm stuck at getting data from a certain api. I get "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access" error.
As I suppose the server is missing the "Access-Control-Allow-Origin" headers in order to enable CORS but what I don't understand is why when I'm trying to make an AJAX call with "Restlet Client - REST API testing" browser extension it actually works. I get a following success response. But It doesn't work inside my actual React Request. Is there a way I can to get rid of this error without any changes on the server side? Why does this extension actually work?
Connection: keep-alive
Content-Type: application/json; charset=UTF-8;
Date:
2017 Sep 22 22:45:40-1m 50s
Server: ..../1.6.2
Transfer-Encoding: chunked
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
My React code but nothing special in there, just testing if I'm getting a response
componentWillMount() {
const url = "https://myserver.ru/api/issue?perPage=10";
Request.get(url).then((response) => {
this.setState({
issues: response
});
});
}
If you are making a cross-site requests then browser will expect Access-Control-Allow-Origin headers from the server. The value of that header can be,
Access-Control-Allow-Origin: *
or
Access-Control-Allow-Origin: http://localhost:3000
When you are requesting from localhost, make sure it also need to add port number as well.
More about CORS documentation:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Hope it helps.

Structr CORS api request

I'm trying to make a XHR request from my AngularJS instance running on port :8080 to my Structr instance running on port :8082
Thing is, Structr doesn't seem to accept OPTIONS requests on port:8080
Here is the Request header :
OPTIONS /structr/rest/issues HTTP/1.1
Host: localhost:8082
Connection: keep-alive
Cache-Control: max-age=0
Access-Control-Request-Method: GET
Origin: http://localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
Access-Control-Request-Headers: accept, -hx-password, -hx-user
Accept: */*
Referer: http://localhost:8080/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4,nl;q=0.2
Here is the Response headers from the server:
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Methods:GET,PUT,POST
Access-Control-Allow-Origin:http://localhost:8080
Content-Length:44
Content-Type:application/json; charset=utf-8
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Server:Jetty(9.1.4.v20140401)
Set-Cookie:JSESSIONID=1w7n8c71lcbh31s7kwygtat69c;Path=/
The most interesting part IMHO is
Access-Control-Allow-Methods:GET,PUT,POST
I have to say that my understanding of java and HTTP Requests is really sparse so I don't really feel like digging in the source code...
Or maybe it's a simple Angular thing everyone knows but me...
Thanks to Axel Morgner the answer is :
There are two ways to solve it:
1: Let Structr serve also the AngularJS code.
2: Configure the REST > endpoint to accept OPTIONS using a ResourceAccess flag, see docs.structr.org/rest-user-guide#Securing > REST Endpoints.
Beware that when you create a Schema, structr automatically creates new resourceAccess nodes for the new possibles actions.

Cross-origin POST request not working even though it is allowed (GET works)

I have a weird problem. I am testing this using Angular.js 1.2.15.
I want to send a POST request to a RESTful API backend on another domain (and I want to use $http directly, not $resource).
var mapData = {
'some': 'keys',
'other': 'keys'
}
$http.post(endPoint, mapData);
This is what happens: An OPTIONS request is sent first, with the following request headers:
OPTIONS /api/maps HTTP/1.1
Host: myhost.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://0.0.0.0:9000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/36.0.1985.125 Chrome/36.0.1985.125 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://0.0.0.0:9000/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
The response clearly shows that requests from other origins and with every method are allowed:
HTTP/1.1 204 No content
Server: Varnish
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Access-Control-Max-Age: 0
Content-Type: text/plain charset=UTF-8
Accept-Ranges: bytes
Date: Tue, 02 Sep 2014 14:50:16 GMT
X-Varnish: 166874803
Age: 0
Via: 1.1 varnish
Connection: close
Cache-Control: max-age=0, private
X-Varnish-Cache: MISS
But then, the POST request is not even sent by the browser (Chromium 36), i.e. it does not show a POST request in the network tab of the dev console.
Instead, the following is shown in the console:
XMLHttpRequest cannot load http://myhost.com/api/maps. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://0.0.0.0:9000' is therefore not allowed access.
Now, what is totally weird: GET requests to the same API work, and are not preceded by an OPTIONS request (or maybe it is not shown in the network tab).
HTTP/1.1 304 Not Modified
Server: nginx/1.4.7
Content-Type: application/json; charset=utf-8
Status: 200 OK
X-UA-Compatible: IE=Edge,chrome=1
ETag: "baca3b7547fed3377088eb81fe083ff8"
X-Request-Id: b2552dc4fdef2541c841e3d5e12d337e
X-Runtime: 0.110003
X-Rack-Cache: miss
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Accept-Ranges: bytes
Date: Tue, 02 Sep 2014 14:54:31 GMT
X-Varnish: 166874831 166874142
Age: 6223
Via: 1.1 varnish
Connection: keep-alive
Cache-Control: max-age=0, private
X-Varnish-Cache: HIT
I really have no clue what the problem could be here. Is it Angular's implementation? Or is it a misconfiguration on the server? The guys responsible for the API told me it usually works with all their web apps.
I understand that this is a CORS problem and I am by no means an expert when it comes to that, but hey, Access-Control-Allow-Origin: * should do the trick, shouldn't it?
UPDATE: It works when using plain XMLHttpRequest:
var http = new XMLHttpRequest();
var url = endPoint;
var params = JSON.stringify(mapData);
http.open("POST", url, true);
I get a 200 back.
What is the matter here?
Nginx has to be compiled with http://nginx.org/en/docs/http/ngx_http_headers_module.html for Access-Control-Allow-Origin: * to work. Do you have this module installed?
location / {
add_header Access-Control-Allow-Origin *;
}

How to avoid infinite loop when trying to load a 404-Not-Found favicon in Chrome?

I've read that Chrome keeps asking for the favicon in each page it visits (link), and if it doesn't find it (404 Not found) then Chrome enters in a infinite loop.
I'm afraid that is happening to my app, although it works fine with Firefox or Safari. I haven't found a way to prevent this after go through all the forums I could find.
The http headers before the problematic request is:
GET /url?file_id=0B0orkZUr6JxAdmViVmNuTG5XbFU HTTP/1.1
Host: glinksapp.appspot.com:443
Accept: image/webp,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: SID=DQAAAHABAACKf5HqkBRzvi3HwJrZJ1nW31wx9PEvsqASLQKFZts0Ux1pWFwk...[cut]
Referer: https://www.google.es/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Chrome-Variations: COS1yQEIl7bJAQiptskBCMG2yQEIm4TKAQj4hMoBCLeFygEIwoXKAQjRhcoB
X-Purpose: Instant
HTTP/1.1 302 Found
content-length: 0
content-type: text/html
date: Sun, 14 Jul 2013 08:59:56 GMT
location: https://drive.google.com/#folders/0B0orkZUr6JxAVk9xT3QxcXBpdWs
server: Google Frontend
status: 302 Found
version: HTTP/1.1
And this is the infinite loop in Chrome:
GET /favicon.ico HTTP/1.1
Host: drive.google.com:443
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: NID=67=fwmd6KsM_Y0xNrRMQlSSpVVmsKTgAi8v4AlG9A...[cut]
PREF=ID=ad9194453b59885b:FF=0:LD=en:TM=1373791886:LM=1373792185...[cut]
SID=DQAAAHABAACKf5HqkBRzvi3HwJrZJ1nWZBxbrbYxeGjE4p130PeYTaQhalIhrt6T-...[cut]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Chrome-Variations: COS1yQEIl7bJAQiptskBCMG2yQEIm4TKAQj4hMoBCLeFygEIwoXKAQjRhcoB
HTTP/1.1 404 Not Found
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-encoding: gzip
content-length: 117
content-type: text/html; charset=UTF-8
date: Sun, 14 Jul 2013 08:59:56 GMT
expires: Fri, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: GSE
status: 404 Not Found
version: HTTP/1.1
x-chromium-appcache-fallback-override: disallow-fallback
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
If you refresh the page, the app comes out from the loop.
My Java app's url is http://glinksapp.appspot.com and is hosted in Google App Engine. It is a drive app to open link files (webloc, url...) directly in Google Drive (something not provided by Google by default).
The question is: how to avoid entering in the 404 'Not found' loop when the app tries to reach 'drive.google.com/favicon.ico'?
Thx in advance.
Chrome and other browsers automatically request the favicon, but they don't enter an infinite loop when they get a 404 (which happens on a lot of sites, so that would be a gigantic problem). The link you posted says that Chrome on Android may request the apple-touch-icon files as well, but that's okay.
The HTTP 404 response you've pasted into your question looks totally fine. Your 302 redirect also looks fine. So I suspect the problem you're experiencing is something else, not related to the favicon.

Resources