I'm trying to access an API via VB6.
I'm successfully able to "POST" AND "GET".
Now running into problems with "PUT"
I'm able to "PUT" using Postman but cannot get it to work in my VB6 Code (able to "GET" and "POST" though)
If i do a
objWinHttp.GetAllResponseHeaders
I get:
**Allow: OPTIONS, GET, POST, HEAD**
Content-Length: 2
Content-Type: application/json
Server: cloudflare
Set-Cookie: __cfduid=dade65e860f9164a08757164f49c2c6ce1524753607; expires=Fri, + 26-Apr-19 14:40:07 GMT; path=/; domain=.monday.com; HttpOnly; Secure
Status: 405 Method Not Allowed
Strict-Transport-Security: max-age=31536000
X-Rack-Cache: invalidate, pass
X-Request-Id: 55aba84b06aaaf03f1e4127ddf9a603a
X-Runtime: 0.009866
X-UA-Compatible: IE=Edge,chrome=1
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
CF-RAY: 4119cd7c1f1571d9-ORD
I'be tried modifying the Header "Allow" by using
ObjWinHttp.SetRequestHeader "Allow", "GET, POST, OPTIONS, PUT, DELETE"
and
objWinHttp.setRequestHeader "Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, DELETE"
to no luck
Any ideas as to why I can't allow PUT requests or another reason this won't work.
You can't demand that the server change itself by trying to send a response header as a request header. The server may not be able to process a PUT method at all anyway rather than simply disallowing them.
For a normal simple-minded page-serving web server a PUT is an attempt to replace a static page, server-side script, or other resource. Why would they ever allow just anybody to hack them like that?
Related
I would like to use amp-list on a website that is otherwise valid AMP to avoid using an amp-iframe embed with JS. I just finished reading the cors docs by Google AMP at https://www.ampproject.org/docs/fundamentals/amp-cors-requests and am still confused - is it possible to have the json source for the amp-list from a remote domain?
The thing I need is to have a source of URLs+titles generated and updated outside of the main jekyll website because the main website takes too long to build.
I am testing it with a valid JSON and headers as follows and am getting nothing in console and the list is not rendered, so I presume what I am trying to do is not possible?
/source.json
Content-type: application/json; charset=utf-8
X-Frame-Options: ALLOW
Access-Control-Allow-Headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://fakename.netlify.com/
AMP-Access-Control-Allow-Source-Origin: https://fakename.netlify.com/
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin
I have http get method called by client side to the server, but when ran it, the method is OPTIONS, here is the output i am seeing in Chrome Dev tools, for the GET Method,
Request URL: http://localhost:9090/area
Request Method: OPTIONS
Status Code: 500
Remote Address: [::1]:9090
Referrer Policy: no-referrer-when-downgrade
Response headers,
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: http://localhost:4201
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: close
Content-Length: 0
Date: Tue, 20 Mar 2018 18:49:59 GMT
Expires: 0
Pragma: no-cache
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
and Request headers are,
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: authorization,content-type
Access-Control-Request-Method: GET
Connection: keep-alive
Host: localhost:9090
Origin: http://localhost:4201
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Why the GET method is not getting called, i know there are already some answers here, but i did not understand well, can some one please help me for clear understandig? Thank You in advance.
The OPTIONS request is what is called a preflight request from the browser. In a simple way is basically the browser sending an initial request to the server asking for permission to then do a GET or POST or any other verb. This happens whenever a request needs permissions to be executed. If the server replies saying you have permissions to run the request you intend to, it will then perform the initial request (GET in this case). If the OPTIONS request is denied, it will not execute any subsequent request. You can see it as a way of testing the waters for requests :)
The reasons to be denied may be several. You might not have the correct headers, you might be missing authentication or authentication token, and so on.
From what I can see on your requests you are doing the requests from localhost to localhost. That will cause you problems with CORS.
Here’s a link on how to configure CORS for spring ( the server you said you are using in the comments below )
I'm writing a vue app to post data using axios to an API powered by laravel. The APIhas a POST route which is to create a resource. I have CORS set up which allows successful GET'ing of the data. However when I try to POST the data, the network tab shows an OPTIONS request being made with nothing being returned and no POST request follows.
Using axios: a POST request is made with: axios.post(url);
but no POST request is actually made, only the OPTIONS request with: axios.post(url,data).
I made a simple api with slim and didn't have similar problems, so I'm assuming this is something laravel specific?
There are no server log errors, the laravel log shows no errors neither. The error in the browser console is: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://api/api/zones/save. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
UPDATE
These are the headers that are sent as the request:
Host: apiurl
User-Agent: ....
Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Origin:null
DNT: 1
Connection: keep-alive
I understand about the pre-flight but the API I made with slim passed the pre-flight using the same axios code and the post request was made. I'm not sure why the laravel API isn't doing so.
UPDATE 2
These are the headers for the OPTIONS response
Server nginx/1.10.3 (Ubuntu)
Content-Type text/html; charset=UTF-8
Transfer-Encoding chunked
Connection keep-alive
Allow GET,HEAD,POST
Cache-Control no-cache, private
Date Fri, 03 Nov 2017 20:46:47 GMT
Content-Encoding gzip
and this is the code I'm using for the laravel middleware:
public function handle($request, Closure $next)
{
return $next($request)
->header('Access-Control-Allow-Origin', '*')
->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS')
->header('Access-Control-Allow-Headers', 'X-Requested-With, Content-Type, Accept, Origin, Authorization')
;
}
}
I'm including this code in the Kernel under the 'api' key
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