I m using Chilkat ActiveX (Delphi) version 9.5.
I use TChilkatHTTP to POST some data to a HTTPS url.
http.SynchronousRequest(Host,443,0,req.ControlInterface);
The response I got is "The plain HTTP request was sent to HTTPS port"
I have googled many days for a solution but unable to find a working solution. Pls if anyone know what have I missed.
Thanks a lot.
Below is the Chilkat log:
---- Sending ----
POST /qrCreate HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: api-testing.payhalal.my
Content-Length: 232
app_id=app-testing-d2277670007a30c2e6b6919fdfc696dd&amount=¤cy=MYR&product_description=MY%20PRODUCT&order_id=12345&customer_name=SHELY&customer_email=eeshely%40gmail.com&customer_phone=0127806698&language=EN&timeout=3600&hash=
---- Received ----
HTTP/1.1 400 Bad Request
Server: nginx
Date: Thu, 12 Sep 2019 10:23:07 GMT
Content-Type: text/html
Content-Length: 264
Connection: close
Strict-Transport-Security: max-age=31536000; includeSubDomains
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
Change
http.SynchronousRequest(Host,443,0,req.ControlInterface);
to this:
http.SynchronousRequest(Host,443,1,req.ControlInterface);
The 3 argument indicates whether TLS should be used. The 2nd arg is just the port number.
Related
I'm trying to read out the cookies from a response in flutter web app. Unfortunately I can't read it out although the browser can (Brave, chromium).
I'm doing a post request using dio. As interceptor for getting all cookies from a response automatically, i've added dio cookie manager to it:
var dio = Dio();
var cookieJar = CookieJar();
dio.interceptors.add(CookieManager(cookieJar));
I also added the LogInterceptor class to it.
Here's the problem:
In the browser I can see that a cookie is set in response header using chrome Dev Tools > Network and examining the request:
Request:
Request URL: https://123.123.123.123/api/login/password
Request Method: POST
Status Code: 200 OK
Remote Address: 123.123.123.123:443
Referrer Policy: strict-origin-when-cross-origin
Response:
Access-Control-Expose-Headers: Set-Cookie
Content-Length: 24
Content-Type: application/json
Date: Fri, 18 Jun 2021 13:55:05 GMT
Server: MyServer
Set-Cookie: my-cookie-session=123456789; Expires="Fri Jun 18 14:55:05 2021"; SameSite=Strict
The LogInterceptor prints this into the console:
*** Response ***
uri: https://123.123.123.123/api/login/password
statusCode: 200
headers:
access-control-expose-headers: Set-Cookie
content-length: 24
content-type: application/json
date: Fri 18 Jun 2021 13:55:05 GMT
server: MyServer
When printing out how much and which cookies are in the jar after that, the result is 0 and an empty list:
cookieJar.loadForRequest(_getUrl("/api/login/password")).then((value) {
print("CookieCount: " + value.length.toString());
value.forEach((element) {
print(element.name + " " + element.value.toString());
});
});
CookieCount: 0
Does someone know why the browser can read out the cookie but the flutter web app can't? Furthermore the cookie is not set in browser, I can only display it when examining the network requests as stated above.
The similar topic on SO are:
HTTP digest authentication fail due to wrong nonce-count in iOS 10
And it looks more like the symptom mentioned here:
https://forums.developer.apple.com/thread/50617
but still has no answer.
We use AVPlayer to perform the digest authentication, and it's working on iOS 9.
What we capture from Wireshark is below:
iOS9
GET /SD/TestContentsforAndroid/Fireworks.mp4 HTTP/1.1
Host: 192.168.40.1:8081
X-Playback-Session-Id: FE21C8D7-9603-4FDE-A648-7544440BD820
Range: bytes=0-1
Accept: */*
User-Agent: AppleCoreMedia/1.0.0.13A405 (iPhone; U; CPU OS 9_0_1 like Mac OS X; zh_tw)
Accept-Language: zh-tw
Accept-Encoding: identity
Connection: keep-alive
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="Drive", nonce="a56fa5b58b55f5d780fdc2e6232c64b2", qop="auth"
Content-Type: text/html
Content-Length: 351
Date: Wed, 16 Nov 2016 03:26:56 GMT
Server: lighttpd
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>401 - Unauthorized</title>
</head>
<body>
<h1>401 - Unauthorized</h1>
</body>
</html>
GET /SD/TestContentsforAndroid/Fireworks.mp4 HTTP/1.1
Host: 192.168.40.1:8081
Authorization: Digest username="admin", realm="Drive", nonce="a56fa5b58b55f5d780fdc2e6232c64b2", uri="/SD/TestContentsforAndroid/Fireworks.mp4", response="a98e31641aa3930d1eb907dcc9a17963", cnonce="afbc1d37b0fd1302948f8554b7400f30", nc=00000002, qop="auth"
X-Playback-Session-Id: FE21C8D7-9603-4FDE-A648-7544440BD820
Range: bytes=0-1
Accept: */*
User-Agent: AppleCoreMedia/1.0.0.13A405 (iPhone; U; CPU OS 9_0_1 like Mac OS X; zh_tw)
Accept-Language: zh-tw
Accept-Encoding: identity
Connection: keep-alive
HTTP/1.1 206 Partial Content
Content-Type: video/mpeg
Accept-Ranges: bytes
ETag: "1312277247"
Last-Modified: Thu, 31 Jan 2013 06:18:08 GMT
Content-Range: bytes 0-1/131067666
Content-Length: 2
Date: Wed, 16 Nov 2016 03:26:56 GMT
Server: lighttpd
....ftypmp42....isommp42....moov...lmvhd.....U5..U5....X....................................................#...................................iods.......O..)......trak...\tkhd....|%...U5.............................................................#........8.....[mdia... mdhd....|%...U5.........U......-hdlr........vide............VideoHandler.....minf....vmhd...............$dinf....dref............url ........stbl....stsd............avc1...........................8.H...H...............................................0avcC.d.(....gd.(.
Which seems follow RFC standards,
however on iOS 10.2 beta 3
iOS10.2 beta 3
GET /SD/DemoData/TestContentsforAndroid/Fireworks.mp4 HTTP/1.1
Host: 192.168.40.1:8081
X-Playback-Session-Id: 82E92AFC-FC64-4142-AE04-A1E422B92E75
Range: bytes=0-1
Accept: */*
User-Agent: AppleCoreMedia/1.0.0.14C5077b (iPhone; U; CPU OS 10_2 like Mac OS X; zh_tw)
Accept-Language: zh-tw
Accept-Encoding: identity
Connection: keep-alive
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="Drive", nonce="a1c413ee966f67b1c8e0e44af227335c", qop="auth"
Content-Type: text/html
Content-Length: 351
Date: Wed, 16 Nov 2016 03:39:02 GMT
Server: lighttpd
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>401 - Unauthorized</title>
</head>
<body>
<h1>401 - Unauthorized</h1>
</body>
</html>
The server does not receive any further request from AVPlayer on iOS 10.
At first I thought it has same root cause due to wrong nonce-count,
but it seems different.
By the way, change the auth method to BASIC can bypass the problem, but it does not solve the digest issue.
Anyone facing same issue and have other ideas to workaround?
I don't know if Apple noticed this yet.
Update: 20170309
Apple's bug report system change my report to below.
29381646 AVPlayer http digest authentication fail on iOS10+
State: Closed Product:
Rank: No Value
Duplicate of 29218533 (Open or Closed; log in to see the actual state)
However, seems I don't have permission to access 29218533,
so I am unable to track the actual response from Apple now.
I have a webserver (behind an nginx), when I send a bad request to the Rail application (ex: to an URL that does not exist in the app - error 404), I get an error message from webrick, like this :
HTTP/1.1 200 Connection established
HTTP/1.1 400 Bad Request
Server: nginx
Date: Mon, 07 Mar 2016 05:25:02 GMT
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 323
Connection: keep-alive
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD><TITLE>Bad Request</TITLE></HEAD>
<BODY>
<H1>Bad Request</H1>
bad URI `/admin/
boot.ini'.
<HR>
<ADDRESS>
WEBrick/1.3.1 (Ruby/2.2.0/2014-12-25) at
192-168-5-51.compute.internal:3000
</ADDRESS>
</BODY>
</HTML>
Now as you can see this message contains the web server name (WEBrick) the version, as well as the Ruby version.
My question is how can I remove this message (send back empty body)
OR customize the page and remove the <ADDRESS> element ?
I have a WebAPI service deployed on a server. There is also an MVC app for testing the API. One such tester runs on my dev machine and another copy (same version) runs on the server where API resides.
The MVC tester app supports calling API directly and also through a built-in 'proxy' (http handler) to bypass the "Access-Control-Allow-Origin" errors. So for example if I run the tester app on my dev machine and I want to receive data from the server, I must use the proxy. This setup works nicely and all of the calls are going through and data is passed properly.
Problem occurs when I don't provide enough inputs (for testing purposes) and API generates a "400 Bad request" error. It only happens when I make a call from my dev machine to remote machine and works fine if I make the same call on the server.
I tested with Postman on the remote server:
post directly to API: POST to 177.77.77.77/v1/feature {JSON payload}
the response I get back contains proper headers, a body with a JSON object describing the error. Same thing happens when I send the same exact command but through server's proxy:
post through proxy: POST to 177.77.77.77/proxy/feature {JSON payload}
both results are identical and this is the expected behavior, which I think allows to make a conclusion that proxy is working and API is working.
When I go back to my dev machine and try the same calls, my result for posting directly to API is the same as above but if I use the server's proxy something else happens. Here's output from Fiddler for the working case (from dev machine directly to API):
POST http://177.77.77.77/v1/feature HTTP/1.1
Host: 177.77.77.77
Connection: keep-alive
Content-Length: 514
User-Agent: Mozilla/5.0 xx..
Cache-Control: no-cache
Origin: chrome-extension://xx-postman-xx
Authorization: Basic pwd=
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
{payload}
response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 15:48:52 GMT
Content-Length: 139
{"code":"INVALID_REQUEST","message":"proper error message"}
this is the correct behavior with expected message body (JSON) and correct content-lenght. If I make a request to the server's proxy, my request becomes:
POST 177.77.77.77/proxy/feature HTTP/1.1
Host: 177.77.77.77
Connection: keep-alive
Content-Length: 514
User-Agent: Mozilla/5.0 xx..
Cache-Control: no-cache
Origin: chrome-extension://xx-postman-xx
Authorization: Basic pwd=
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: appSettings=xx
{payload}
then the response I get is:
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 15:51:37 GMT
Content-Length: 11
Bad Request
the body/payload of the response is lost or replaced by status, content-type changed from JSON to text/html and cache-control became private.
The cookie in the non-working case plays no role. I tried removing it and result is still wrong.
Why do you think this is happening? How can I troubleshoot this and find what portion of code (or maybe IIS setting?) is responsible for sending a different response for what seems to be same requests? After all everything works fine when I run only on dev or only on remote. Could this be some permission issue or something in IIS on the server?
I tried remote-debugging of the proxy code where I would step through the code while sending Post commands (with the same payload) through Postman. In one scenario I ran Postman on the server and made a request to server's proxy and in another scenario I ran Postman on dev and also made requests to server's proxy. In VS I can see that I'm going through the same path in code for both scenarios and that API's response is the same.
Thanks for reading and any attempts to help will be greatly appreciated!
added this to web.config:
<system.webServer>
<httpErrors existingResponse="PassThrough"></httpErrors>
</system.webServer>
found the solution here:
In IIS7.5 what module removes the body of a 400 Bad Request
I'm using a CXF client to communicate with a .net web service running on IIS 6.
This request (anonymised):
POST /EngineWebService_v1/EngineWebService_v1.asmx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://.../Report"
Accept: */*
User-Agent: Apache CXF 2.2.5
Cache-Control: no-cache
Pragma: no-cache
Host: uat9.gtios.net
Connection: keep-alive
Transfer-Encoding: chunked
followed by 7 chunks of 4089 bytes and one of 369 bytes, generates the following output after the first chunk has been sent:
HTTP/1.1 404 Not Found
Content-Length: 103
Date: Wed, 10 Feb 2010 13:00:08 GMT
Connection: Keep-Alive
Content-Type: text/html
Anyone know how to get IIS to accept chunked input for a POST?
Thanks
Chunked encoding should be enabled by default. You can check your setting with:
C:\Inetpub\AdminScripts>cscript adsutil.vbs get /W3SVC/AspEnableChunkedEncoding
The 404 makes me wonder if it's really a problem with the chunked encoding. Did you triple-check the URL?
You may well have URLScan running on your server. By default URLScan is configured to reject requests that have a transfer-encoding: header and URLScan sends 404 errors (which is conspicuous over a proper server-error).
UrlScan v3.1 failures result in 404 errors and not 500 errors.
Searching for 404 errors in your W3SVC log will include failures due
to UrlScan blocking.
You will need to look at the file located in (path may differ) C:\Windows\System32\inetsrv\URLScan\URLScan.ini. Somewhere in there you will find a [DenyHeaders] section, that will look a bit like this (it will probably have more headers listed).
[DenyHeaders]
transfer-encoding:
Remove transfer-encoding: from this list and it should fix your problem.