In the example at http://alx3apps.appspot.com/jsonrpc_example/ when I click the submit button, I notice (by using Firebug) that my browser submits the source:
{"params":["Hello ","Python!"],"method":"concat","id":1}
It's not posting a parameter (eg. json=[encoded string from above]), but rather just posting a raw string with the above value.
Is there an widely accepted way to replicated this via a GET request, or do I need to just urlencode the same string and include it as http://www.example.com/?json=%7b%22params%22%3a%5b%22Hello+%22%2c%22Python!%22%5d%2c%22method%22%3a%22concat%22%2c%22id%22%3a1%7d? I understand that some older browsers cannot handle a URI of more than 250 characters, but I'm OK with that.
A GET request doesn't usually transmit data in any other way besides headers, so you should pass the string encoded in the URL if you wish to use GET.
POST http://alx3apps.appspot.com/jsonrpc_example/json_service/ HTTP/1.1
Host: alx3apps.appspot.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/json-rpc; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://alx3apps.appspot.com/jsonrpc_example/
Content-Length: 55
Pragma: no-cache
Cache-Control: no-cache
{"params":["Howdy","Python!"],"method":"concat","id":1}
In a normal form post the header Content-Type: application/x-www-form-urlencoded lets the server know to expect the format in key=val format whereas the page you linked sends Content-Type: application/json-rpc; charset=UTF-8. After the headers (which are terminated with the blank line) the data follows in the specified format.
You are correct that only POST submits data separately from the URI. So urlencoding it into the querystring is the only way to go, if you must use GET. (Well, I suppose you could try setting custom request headers or using cookies, but the only "widely accepted" way is to use the querystring.)
Related
I've been trying to create an app which does some requests on Wizzair api, and found that there is this endpoint as /Api/search/search. While searching for flights in the browser this endpoint returns a list of flights based on the parameters provided as a json response. While accessing the same endpoint from postman and copying the same headers and body as the request I get a 428 response. That seems kinda odd, since the headers and body are exactly the same as the one in the Newtork tab in the Developer tools.
Here's a reference URL: https://wizzair.com/#/booking/select-flight/LTN/VIE/2022-07-23/2022-08-05/1/0/0/null
The added headers are:
Host: be.wizzair.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://wizzair.com/
Content-Type: application/json;charset=utf-8
X-RequestVerificationToken: <token>
Content-Length: 254
Origin: https://wizzair.com
Connection: keep-alive
Cookie: <some_cookies>
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
TE: trailers
And the body is added as raw json:
{"isFlightChange":false,"flightList":[{"departureStation":"LTN","arrivalStation":"VIE","departureDate":"2022-07-24"},{"departureStation":"VIE","arrivalStation":"LTN","departureDate":"2022-08-05"}],"adultCount":1,"childCount":0,"infantCount":0,"wdc":true}
The response from postman is:
{"sec-cp-challenge": "true","provider":"crypto","branding_url_content":"/_sec/cp_challenge/crypto_message-3-7.htm","chlg_duration":30}
Could anyone explain to me why there is a different behavior on the browser vs postman on the exact same request and if possible replicate the proper response in postman?
Don't know if it is still relevant.
But this one
{"sec-cp-challenge": "true","provider":"crypto","branding_url_content":"/_sec/cp_challenge/crypto_message-3-7.htm","chlg_duration":30}
enter code here
is a fingerprint of akamai bot protection. AFAIK it uses JS to tell real browser from scripted requests. It stores result in cookies, obfuscating it an every possible way. Good thing is that you can copy cookies from your browser session, and that way have several requests with meaningful results. After that akamai starts to try to change cookies again, and you'll have to start all over.
I really want some validation after reading many websites on CORS to see if I have this
OPTIONS /frog/LOTS/upload/php.php HTTP/1.1
Host: staff.curriculum.local
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Origin: http://frogserver.curriculum.local
Access-Control-Request-Method: POST
Access-Control-Request-Headers: cache-control,x-requested-with
Pragma: no-cache
Cache-Control: no-cache
Here is when I think I respond with 403 ->
If my origin set on the server is not * and not that domain, I response with 403.
If I do not support POST (I may support GET), I respond with 403
If I do not support any ONE of the request headers, I respond with 403
For #1, if the domain is not supported, I will NOT send any Access Control headers in the response. I think that is ok.
for #2 and #3, I would send these headers assuming Origin request header was a match
Access-Control-Allow-Origin: http://frogserver.curriculum.local
Access-Control-Allow-Credentials: {exists and is true IF supported on server}
Access-Control-Allow-Headers: {all request headers we support and not related to incoming 'Access-Control-Request-Headers' in the request}
Access-Control-Allow-Methods: {all methods supported NOT related to incoming method POST that came in?}
Access-Control-Expose-Headers: {all headers we allow browser origin website to read}
Is my assumption correct here? or are some of the response headers related to the request headers in some way I am not seeing? (The names are similar but I don't think the behavior is tied to each other).
I would find it really odd that the request even needs to contain Access-Control-Request-Method & Access-Control-Request-Headers if we did not send back a 403 in the cases where we don't support all requested information on that endpoint, right? This is why I 'suspect' we are supposed to return a 403 along with what we do support?
thanks,
Dean
This is an example of HTTP request message transmitted to the web server. Inside headers there is an Accept header. I am confused about the meaning of it and how it is created. I thought it solely specifies my browsers capabilities to handle files. But that doesn't explain why does it differ when I visit amazon.com or joes-hardware.
There is also Content-Type header, which is a MIME for a file it requested. Same question. How does my browser know what is the type of file it requested? Is it based on the URI extension I requested or is this a generic header? This header seems to only be send in response headers. My mistake.
GET /tools.html HTTP/1.0
User-agent: Mozilla/4.75 [en] (Win98; U) Host: www.joes-hardware.com
Accept: text/html, image/gif, image/jpeg
Accept-language: en
First things first: Acceptand Accept-Language are headers defined in RFC 7231, section 5.3.2 and section 5.3.5, respectively. Together with Accept-* headers, they enable content negotiation through the client. There is an excellent article regarding content engotiation on the Mozilla Development Network. (On a side-note: The MDN is an excellent starting point for research. A lot of the articles are outdated, but the concepts are still largely valid)
The content of the Accept-Language is largely controlled by the language settings of a client's UI. Mozilla's Firefox (and - IIRC - Opera and Safari) allows to tweak these through its settings while MSIE seems to deduct them from the keyboard layouts installed in the system. There is nothing in the type of requested media that should influence this header.
The content of the Accept header on the other hand is very much depending on the context in which a resource is being requested. E.g. if you request a resource through your browser's address bar, the Accept header will pretty much read like "give me anything I can digest." If the browser is requesting a resource through an <img/>-tag, the header is going to differ in that the browser is trying to get a presentation of the requested resource that is fit for being displayed inside that tag. Same for <video/>, <audio/>, and <script/>.
Beyond that, I am not aware of any mechanisms effecting the Accept header. <a/>-tags have - unknownst to most - a type attribute which is carrying a MIME mediatype. This is, however, a fallback mechanism and should not alter Accept in any way.
As for your example, I took the liberty of requesting both sites and copying the relevant request headers:
amazon.com
GET / HTTP/1.1
Host: www.amazon.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
joes-hardware.com
GET / HTTP/1.1
Host: www.joes-hardware.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
The headers are no different when requesting /tools.html in the last example.
If my browser uses cache (local cache), does it GUARANTEE that each HTTP request it sends contains "IF MODIFIED SINCE" header line?
If not, how do I define that it will ? and what if I define a proxy server to the browser ? will it add it automatically then?
thanks in advance
I was just working on this with my RESTful web service and ran a few tests for a particular resource. First of all I was trying to control the browser cache from my web server by setting the following HTTP headers on the HTTP response for the resource:
Cache-Control: must-revalidate, max-age=30
Last-Modified: Mon May 19 11:21:05 GMT 2014
Expires: Mon May 19 11:51:05 GMT 2014
Then from my web UI I have a timer that periodically (every 5 seconds) does a GET on the resource that I've said is cacheable. Since the resource in the browser cache has not yet expired the GET request for the resource is served from the browser cache, however, once the "max-age" has expired the next GET request goes to the server and the browser adds the "If-Modified-Since" header with the "Last-Modified" date as the value like this:
[GET] - /cms_cm_web/api/notification
referer: http://localhost:8080/cms_ui/#/
accept: application/json, text/plain, */*
accept-language: en-us
ua-cpu: AMD64
accept-encoding: gzip, deflate
user-agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
host: localhost:8080
if-modified-since: Mon, May 19 11:21:05 GMT 2014
connection: Keep-Alive
This came from IE9 browser. I get the same from latest Firefox and Chrome browsers as well.
From here the server can look for the "If-Modified-Since" header and if it determines the resource has not been modified then it returns a 304 Not Modified response, otherwise, it returns the resource representation with a 200 OK response.
so according to the HTTP specification you can control caching using "Expires" and/or "Cache-Control" headers together with a "Last-Modified" header. This will cause the browser cache to perform what's called a "conditional GET" request as it includes the "If-Modified-Since" header.
I am developing with the .NET framework, using jQuery 1.4.2 client side.
When developing in Firefox version 3.6, every so often an one of the many ajax calls I make on the page will fire twice, the second will return successfully but will not trigger the success handler of the ajax call and the first never returns anything. So basically the data is all sent to the server and response is sent down but nothing happens with the response.
Here is an example of the call I am making. It happens to any of the ajax calls, so there is not one particular that is causing the problem:
$.ajax({
type:"POST",
contentType : "application/json; charset=utf-8",
data:"{}",
dataType:"json",
success:function(){
alert('success');
},
error:function(){
alert('error');
},
url:'/services.aspx/somemethod'
});
})
From firebug, here are the headers of the first call which in firebug shows as never completely responding, meaning i see no response code and the loader gif in the firebug never goes away.
Note:In firebug it usually says Response Header but for the first call this space is blank
Server ASP.NET Development Server/9.0.0.0
X-AspNet-Version 2.0.50727
Content-Type application/json; charset=utf-8
Connection Close
Request Headers
Host mydomain.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3)
Gecko/20100401Firefox/3.6.3 ( .NET CLR 3.5.30729)
Accept application/json, text/javascript, */*
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/json; charset=utf-8
X-Requested-With XMLHttpRequest
Referer http://mydomain.com/mypage.aspx
Here is the header from the second request which just appear to complete in firebug (i.e response is 200):
Response Header
Server ASP.NET Development Server/9.0.0.0
X-AspNet-Version 2.0.50727
Content-Type application/json; charset=utf-8
Connection Close
Request Headers
Host mydomain.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3)
Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/json; charset=utf-8
Referer http://mydomain.com/mypage.aspx
To summarize my question, why are two requests being made and why are neither of them triggering a success or error handler in the ajax call.
I have seen this article about firefox 3.5+ and preflighted requests
https://developer.mozilla.org/En/HTTP_access_control#Preflighted_requests
In the article is says if a "POST" is made with any other content type than
"application/x-www-form-urlencoded, multipart/form-data, or text/plain" than the request is pre-flighted. If this is the case, this should happen to all of my calls.
Thanks
This isn't an answer as much as a proposed temporary workaround. Make the call synchronous with async:false and see if things work again.
I've been tearing my hair out over a similar-sounding bug recently.