Backend server : springboot 2.6.3
Case1, Http Request
Get * HTTP1/1
Accept: */*
Http Response
Content-Type: application/json or application/json;charset=UTF-8
In mobile, when I request at Chrome & Safari browser,
response entity content-type is "application/json",
there is a character encoding problem about korean or else character
In mobile, when I request at Chrome & Safari browser,
response entity content-type is "application/json;charset=UTF-8",
there is no problem character encoding about korean or else character
Q: what is different between application/json and application/json;charset=UTF-8?
; The reason, no problem character encoding "application/json;charset=UTF-8"
Case2, Http Request
Get * HTTP1/1
Accept: */*
Http Response
Content-Type: application/json or application/json;charset=UTF-8
In pc, when i request at Chrome, response entity content-type is
"application/json;charset=UTF-8", or "application/json;charset=UTF-8"
there is no problem charactor encoding about korean or else character
Q: Regardless content-type, why pc browser has nothing problem about character encoding?
plz save me... i wanna go home ... plz..
if you have content-type content'charset=UTF-8',you will have 'charset=UTF-8'.if you
do not have it, the PC system or mobile system have default charset. maby you see a wrong char. especially chinese application soft
Related
I posted earlier this post right here
The problem is that when i send my requests after login on my ionic app a have the token stored and I use it to send other request that needs authentication these request has the header like this:
Accept: application/json
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI.....
Content-Type: application/json
Origin: http://localhost:8100
Referer: http://localhost:8100/
An after 3 days of search I figured out the request headers are being ignored by Apache and all requests arrives without token so i get this message error as response from all API routes:
{"message": "Unauthenticated"}
I am requesting mock server with redirect response (HTTP 303)
When I am checking network in Google Chrome (v66.0.3359.170), I can see one additional GET request compared to Firefox (v60.0 Ubuntu)
Request
req.open("POST", "http://localhost:9001/rederict", true);
req.send();
Response for http://localhost:9001/rederict
HTTP/1.1 303 See Other
Location: http://localhost:9001/response
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
Response for http://localhost:9001/response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
{ "Random": "content" }
Firefox network
Chrome network
Is there any reason why chrome requests one additional GET? (the same situation apply if in request I am using GET instead of POST)
As I know that if cors request comes with some extra headers set, first server needs to process it.
With CORS, the server must send the Access-Control-Allow-Headers header to allow uncommon request headers from the client.
Access-Control-Allow-Headers ... - Comma-delimited list of the supported request headers.
e.g suppose my pre-flight request is
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
Then from server-side I will send response
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
My question is -
should I close the connection on server side while we send pre-flight response to client?
One more thing how can I cached pre-flight request for all other distinct subsequent requests?
Thanks
You could cache the OPTIONS request using the
Access-Control-Max-Age
header.
Attach it to the headers collection of the OPTIONS response.
But nevertheless an initial OPTIONS request by the user agent (browser) has to be made, you cannot avoid this.
But all further OPTIONS requests are cached and not issued to the server.
No need to close the connection.
Access-Control-Allow-Origin: http://hello-world.example
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: PUT
as explained here, search for
could have the following headers specified
to get to the designated text section.
While trying to redirect user to a URL, it works with GET requests but not with postback requests.
Through firebug's Network window, I can see the redirect response received by browser after the postback request (that should cause redirect) completes. The browser seemingly initiates a GET request for the redirect URL but doesn't actually successfully redirect. It remains there on the same page.
I use JSF server side. The initiated GET request is not received at all by the server. However initiated by the browser on server's demand. I guess problem is somewhere client side only
Can anyone please explain how to make redirect work successfully ? Let me know incase I should provide any more information.
Edit:
Request header for redirect:
GET /Px10Application/welcome.xhtml HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://localhost:8080/Px10Application/channelPages.xhtml?channelId=-3412&type=Group
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: hb8=wq::db6a8873-f1dc-4dcc-a784-4514ee9ef83b; JSESSIONID=d40337b14ad665f4ec02f102bb41; oam.Flash.RENDERMAP.TOKEN=-1258fu7hp9
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response header for redirect:
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1
Set-Cookie: oam.Flash.RENDERMAP.TOKEN=-1258fu7hp8; Path=/Px10Application
Pragma: no-cache
Cache-Control: no-cache
Expires: -1
Content-Type: text/xml;charset=UTF-8
Content-Length: 262
Date: Wed, 22 May 2013 17:18:56 GMT
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
You're thus attempting to send a redirect on a JSF ajax request using "plain vanilla" Servlet API's HttpServletResponse#sendRedirect(). This is not right. The XMLHttpRequest does not treat a 302 response as a new window.location, but just as a new ajax request. However as you're returning a complete plain vanilla HTML page as ajax response instead of a predefined XML document with instructions which HTML parts to update, the JSF ajax engine has no clues what to do with the response of the redirected ajax request. You end up with a JS error (didn't you see it in the JS console?) and no form of visual feedback if you don't have the jsf.ajax.onError() handler configured.
In order to instruct the JSF ajax engine to change the window.location, you need to return a special XML response. If you have used ExternalContext#redirect() instead, then it would have taken place fully transparently.
externalContext.redirect(redirectURL);
However, if you're not inside JSF context, e.g. in a servlet filter or so, and thus don't have the FacesContext at hands, then you should be manually creating and returning the special XML response.
if ("partial/ajax".equals(request.getHeader("Faces-Request"))) {
response.setContentType("text/xml");
response.getWriter()
.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>")
.printf("<partial-response><redirect url=\"%s\"></redirect></partial-response>", redirectURL);
} else {
response.sendRedirect(redirectURL);
}
If you happen to use JSF utility library OmniFaces, then you can also use Servlets#facesRedirect() for the job:
Servlets.facesRedirect(request, response, redirectURL);
See also:
Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same
JSF Filter not redirecting After Initial Redirect
I'm developing an API proxy in Apigee EDGE to expose a Target API in SOAP (XML) to a REST/JSON endpoint with a fairly simple XMLtoJSON and a AssignMessage policy.
Until I just noticed that some characters in the final JSON were displayed as "?" while in the original SOAP (XML) response the same characters were correctly displayed as "á" for example.
Then I noticed that the response from the Target API endpoint came in as:
Content-Type: text/xml; charset=iso-8859-1
While my intention is to output a properly encoded UTF-8 response as:
Content-Type: application/json; charset=utf-8
So my question is: Is there a way to convert the character encoding from iso-8859-1 to UTF-8 using just standard Policies? without incurring in going to Node, Java, Javascript or Python policies to do this simple character encoding?
You should be able to just set the appropriate encoding in a Content-Type header on the response using the AssignMessage policy... Does that work?