I want to make a post request using HttpClient or XMLHTTP similar to this.
POST http://www.indianrail.gov.in/cgi_bin/inet_trnnum_cgi.cgiHTTP/1.1
Host: www.indianrail.gov.in
Connection: keep-alive
Content-Length: 39
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://www.indianrail.gov.in
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://www.indianrail.gov.in/train_Schedule.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
lccp_trnname=19329&getIt=Please+Wait...
Have seen the code sample of httpclient, but I didn't understand much from that.Typically facing the problem in setting the headers.Below is what I have tried.Also, want to know how to send the string( lccp_trnname=19329&getIt=Please+Wait...) to the server.
httpClient = new Windows.Web.Http.HttpClient();
httpClient.defaultRequestHeaders.host(new Windows.Networking.HostName("www.indianrail.gov.in"));
httpClient.defaultRequestHeaders.connection("keep-alive");
httpClient.defaultRequestHeaders.accept("text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
httpClient.defaultRequestHeaders.userAgent.parseAdd("Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)");
httpClient.defaultRequestHeaders.referer("http://www.indianrail.gov.in/train_Schedule.html");
httpClient.defaultRequestHeaders.acceptEncoding("gzip, deflate");
httpClient.defaultRequestHeaders.acceptLanguage("en-US,en;q=0.8");
Related
Hello I have found a parameter in my request header, but I don't know what it is.
Here I give you a sample of my header and the X-MAC parameter that is at the end:
authority: carper-example-api.examplecarper.com
method: POST
path: /auth/login
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,es;q=0.8
content-length: 52
content-type: application/json
origin: https://play.example.com
referer: https://play.example.com/
sec-ch-ua: "Chromium";v="106", "Google Chrome";v="106", "Not;A=Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
x-mac: CEcEdtgZ+hlSIDk+dM/58munhvmsBvQNV6xjDfwRhZ44Q2Ten7H87xtqk0QjFb42f9OKeMDvaTzkJSs/asspMbpRielgAVSYpBJihWn4T0N7XrqTVhhbFhpnTCRBx5Niaetq9BeVS54AP8dO7VMMs1N1A99tbnlLtmk3rSzxeZU=
Did a little bit of research, it looks like it's a protocol for wireless sensor networks.
More can be found here, here and here
Why does browser (Chrome) keep sending GET requests for SSE (Server-Sent Events)? Any idea why?
I only run the 'subscribeMe' function below once via clicking on button on the HTML page.
I understand that SSE works by only one GET is sent, and one 200 OK is received .. then with changes, server only pushes "data: ....." through the kept-open TCP HTTP/HTTPS connection.
const state = ['connecting', 'open', 'closed'];
let EPEvent;
function subscribeMe() {
EPEvent = new EventSource(`/event/${window.sessionStorage.getItem("Token")}/EPRegistration`);
EPEvent.onmessage = function (e) { console.log(state[this.readyState]); console.log(e); console.log(JSON.parse(e.data)) }
EPEvent.onopen = function () { console.log(state[this.readyState]) }
}
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
Cache-Control: no-cache
Date: Sun, 08 Mar 2020 21:07:45 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:48 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:51 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:54 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:57 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:08:00 GMT
Server: Home SE
Content-Length: 14
data: null
Fixed it!
I should have not put 'Content-Length' in my response! .. This is a stream, Content-Length has no meaning.
Now, it is working fine.
I am sending a request to a website ( I am using request module ) and it returns data in response. Everything is working fine until I send request behind a proxy ( even when the proxy is not banned on the site ).
my problem is the same
How to stop NodeJS "Request" module changes request when using proxy
I tried every solution in the above post but nothing helped
Headers I am using in request
Host: www.somesite.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
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, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
I am setting up a server on ESP8266 WiFi module. Basic operation is, you request a URL. ESP serves that page. It has a form. You fill it in and click submit, and the browser sends POST request by AJAX. I am not using jQuery, just js. From Chrome dev-tools, it looks like all is well.
But on the ESP Server side, I noticed I am missing post data once in a while. After digging deep, I found this issue.
Ideal result from Chrome on my windows: And this works correctly. Post data comes in as expected.
+IPD,0,507:POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 63
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=tgfgfdgfdtrd&auth=4
But on my Mac Chrome, I see the following result.
+IPD,0,472:POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 63
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,ml;q=0.6
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
+IPD,0,63:ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfasdf&auth=4
And I can repeat this. The only different in each case is I am using Chrome on Windows as opposed to Chrome on Mac. To double check, I downloaded Chrome canary version and tried. The first request worked fine. From second request onwards, it shows this problem. Why is this happening? Any ideas? May be my laptop has issues? :)
Here are Chrome dev-tools info from Chrome on Mac (the one with the problem)
**Request Headers:**
POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 61
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,ml;q=0.6
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
**Request Payload**
ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfoi&auth=4
+IPD is the AT command that says data was received from the network. +IPD,0,63: is saying to receive 63 bytes from connection 0. That matches with your Content-Length header. Notice that it also appears at the beginning of the header portion of the request.
Your WiFi library on the ESP side is throwing that in. Here and on line 281 is the source code where it might be happening. There are a couple variables that affect whether or not the +IPD is added, maybe you have set or inadvertently changed one.
I have an application posting to an asp.net MVC webservice via Ajax.
This seems to work like a champ in all browsers except IE 9. What could be causing this?
The javascript
console.log(data);
$.ajax
({
type: 'POST',
url: '//localhost:65201/User/CreateAsynch',
data: data,
cache: false,
success: function (response) {
// Do stuff
},
error: function (xhr, msg) {
// Do stuff
}});
The Controller
This is what happens when I post in IE vs other browsers (Chrome, in this example)
See how some of the values are populating?
Then there's IE9
Here's what the requests look like (from fiddler)
Chrome
POST http://localhost:65201/User/CreateAsynch HTTP/1.1
Host: localhost:65201
Connection: keep-alive
Content-Length: 184
Accept: */*
Origin: http://localhost:56076
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:56076/retail/registrationform/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Username=drew.j.wyatt%40gmail.com&FirstName=Drew&LastName=Wyatt&Email=drew.j.wyatt%40gmail.com&RawPassword=boom&RawConfirmPassword=boom&CountryCode=USA&UserTypeID=2&RegisterForStore=31
IE9
POST http://localhost:65201/User/CreateAsynch HTTP/1.1
Accept: */*
Origin: http://localhost:56076
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:65201
Content-Length: 184
DNT: 1
Connection: Keep-Alive
Pragma: no-cache
Username=drew.j.wyatt%40gmail.com&FirstName=Drew&LastName=Wyatt&Email=drew.j.wyatt%40gmail.com&RawPassword=boom&RawConfirmPassword=boom&CountryCode=USA&UserTypeID=2&RegisterForStore=31
What am I missing?