I just want to make sure I have no issue here. Does anybody know what causes the
2017-03-17 07:59:17.5838|1|Microsoft.AspNetCore.Hosting.Internal.WebHost|INFO|Request starting HTTP/1.1 GET http://192.168.20.57:8081/hardware/configuration/active application/json
2017-03-17 07:59:17.5868|4|Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware|DEBUG|The request path /hardware/configuration/active does not match a supported file type
I'm exposing the Web API by Kestrel only (no IISIntegration).
The request header contains
GET /hardware/configuration/active HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json
Defining
[Produces("application/json")]
explicitly in my controller has no effect.
Set StaticFileOptions.ServeUnknownFileTypes to true:
app.UseStaticFiles(new StaticFileOptions()
{
FileProvider = new PhysicalFileProvider("mypath"),
ServeUnknownFileTypes = true // <<<<<<
});
or find out where the unknown types can be extended (please let me know in the latter case).
After the request comes in by kestrel (which is your first log row).
It first goes through a middleware pipeline until it reaches the WebApi middleware.
As you can see in the second logging row: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware. It reached the StaticFileMiddleware and not the WebApi Middleware.
Probably the staticFileHandler finds a file there in the wwwroot folder and thus returns this message? Or Even before it tries to check the filesystem it checks if it is an allowed/known file extension and this is not the case, thus this second log message.
Related
I'm invoking a HTTP GET request to another system using RESTEasy with resteasy-client:3.12.1.Final (provided by WildFly 20.0.1.Final).
ResteasyClient client = new ResteasyClientBuilder().build;
ResteasyWebTarget target = client.target(fromPath(url));
Response response = target.request()
.header(AUTHORIZATION, "Basic <authentication_token>")
.accept(APPLICATION_JSON)
.get()
As you can see, I don't configure anything "special" in the ResteasyClientBuilder but for some reason all requests contain this header parameter: Accept-Encoding: gzip which causes some trouble on the remote side.
The RESTEasy documentation however states:
RESTEasy supports (though not by default - see below) GZIP
decompression. If properly configured, the client framework or a
JAX-RS service, upon receiving a message body with a Content-Encoding
of "gzip", will automatically decompress it. The client framework can
(though not by default - see below) automatically set the
Accept-Encoding header to be "gzip, deflate" so you do not have to set
this header yourself.
From my understanding the gzip parameter should not be set by default. Or are there any other possible default configurations which might add this parameter?
You might want to try this:
Variant variant = new Variant(MediaType.JSON_APPLICATION, "", "gzip");
Response response = client.target(generateURL("/big/send")).request().post(Entity.entity(b, variant));
I don't know if I am not correctly understanding how the caching aspect of ETags work if there is some other issue I am dealing with, but I'll walk you through my situation.
From my understanding ETags are a unique hash that is created based on the file information and they are sent as part of Response header to uniquely identify the file. If the file is updated then the info is changed and hence the ETag for the file is also changed.
In my project, I need a fresh JS file to be fetched everytime I make changes to the file. I can't use version tags or unique hashes as part of the file name. I thought an ETag would work where
Http Request
GET myFile.js
Client ------------------> SERVER
Http Response 200
Http Response Header
accept-ranges: bytes
cache-control: max-age=86400, public
etag: "a7-58c3bb52101c4"
......
myFile.js
Client <------------------ SERVER
// myFile.js has not been changed
Http Request
GET myFile.js
Client ------------------> SERVER
Http Response 304
Http Response Header
accept-ranges: bytes
cache-control: max-age=86400, public
etag: "a7-58c3bb52101c4"
......
Client uses cached version of file
// myFile has been changed
Http Request
GET myFile.js
Client ------------------> SERVER
Http Response 200
Http Response Header
accept-ranges: bytes
cache-control: max-age=86400, public
etag: "88-58c3a1cb8474f" // new etag generated
......
myFile.js
Client <------------------ SERVER
So, if you request the file again and no changes have been made..the etag will remain the same and you'll get a 304 will indicate that the cached version should be used.
If the file has been changed the etag will be different as well and a fresh copy of the file will be sent by the server.
This is how I expected it to work.
MY PROBLEM:
When I update myFile.js it seems like I never get the new ETag has back. It just defaults to the cahced version of the file. If I clear the cache then I get the latest file and the new ETag. This to me seems to defeat the purpose. Is this how it works or am I understanding something incorrectly here?
I am trying to verify an ID Token using the Firebase Admin SDK as per instructions. My current auth code looks like this (in Vue):
// Auth.vue, inside the firebaseui config callback
signInSuccessWithAuthResult: function(authResult, redirectUrl) {
authResult.user
.getIdToken(/* forceRefresh */ true)
.then(function(idToken) {
// Send token to your backend via HTTPS
// ...
console.log(idToken);
})
.catch(function(error) {
// Handle error
console.log(error);
});
The login works fine and I can get authResult perfectly. However, it seems the function getIdToken is the problem, as I get the following error on my console:
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
https://securetoken.googleapis.com/v1/token?key=AIzaSyApp5yu051vMJlNLoQ1ngVSd-f2k7Pdavc.
(Reason: CORS request did not succeed).
In my request list, the one hanging is an OPTIONS method, with the following headers:
OPTIONS /v1/token?key=AIzaSyApp5yu051vMJlNLoQ1ngVSd-f2k7Pdavc HTTP/1.1
Host: securetoken.googleapis.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.8,pt-BR;q=0.5,de;q=0.3
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: POST
Access-Control-Request-Headers: x-client-version
Origin: http://localhost:8080
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I am not even sure where the problem lies. Is it coming from the Vue side? I am running it in a dev server (by simple yarn serve, vue cli 3). Would the solution be when I run Vue on a production server where I can actually configure cors?
Any light on the matter is extremely welcome...
Thanks!!
Figured it out.
I was calling it in the wrong place. What helped was this thread, which pointed me out to Preflighted Requests which is what the OPTIONS request is:
"preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.
So I realized I should not be sending this request within my Post request where I got the authorization in the first place. Moving it to another method made it work.
I am attempting to get some headers sent from my server to my front end via a fetch request.
In the controller function, I am explicitly sending some headers like this:
exports.getItems = async (ctx) => {
ctx.set('Search-type', 'category');
};
In postman, when I make a get request to my server I get these headers:
Connection →keep-alive
Content-Length →6442
Content-Type →application/json; charset=utf-8
Date →Thu, 19 Apr 2018 16:10:54 GMT
Search-type →category
However, when I try to access the header in the fetch request from the front end, I can only log the Content-Type. How do I get Search-type from my fetch?
After some googling, I found this issue on github which seems very similar to mine. This led me to another github issue page with the suggestion that I need to 'expose some explicitly needed headers'.
In the koa/cors documentation, there is an option allowHeaders Access-Control-Allow-Headers what I want to know is, how do I expose the headers so I can get them on my front end?
In the response to the GET, in addition to adding the Access-Control-Allow-Origin response header, you also need to include the Access-Control-Expose-Headers: <comma-separated-list-of-headers> response header.
If that header isn't returned by the server, even though the headers are sent by the server to the browser, the browser blocks any non-standard headers from being accessed by JavaScript. So you can see Content-Type (because it's a 'standard' response header), but not Search-type.
Basically, you need to ensure that the server responds with this
Access-Control-Expose-Headers: Search-type
(in addition to any other CORS response headers, like Access-Control-Allow-Origin, of course).
I have a RESTFul service written in Finch framework with multiple endpoints. Some of the endpoints needs to support JSONP for cross domain requests. By checking the source code of Finch it looks like there is not an easy way of doing so. I've found this page kind of related but not quite knowing the details.
https://groups.google.com/forum/#!topic/finaglers/nAaCfOiLp1w
Can someone give me some guideline/example ?
My return value want to be look like:
{
ids:[id1,id2,id3...idn]
}
Not going into the details on why JSONP considered insecure (I assume you know that already), the Finaglers thread you're referencing mentions JsonpFilter that can be applied to an HTTP service returning JSON to "upgrade" it to JSONP.
Here is a small example on how to wire this filter with Finch's endpoint.
import com.twitter.finagle.Http
import com.twitter.finagle.http.filter.JsonpFilter
import io.finch._
import io.finch.circe._
val endpoint: Endpoint[Map[String, String]] = get("jsonp") {
Ok(Map("foo" -> "bar"))
}
val service = endpoint.toServiceAs[Application.Json]
Http.server.serve(":8080", JsonpFilter.andThen(service))
JsonpFilter is dead simple. It checks the returned HTTP payload and it's a JSON string, it wraps it with a call to a function whose name is passed in the callback query-string param (and changes the content-type to application/javascript correspondingly). Using httpie, this would look as:
$ http :8081/jsonp
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 39
Content-Type: application/json
{
"foo": "bar"
}
$ http :8080/jsonp?callback=myfunction
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 56
Content-Type: application/javascript
/**/myfunction({"foo":"bar"});