I am faced with the task of logging in and getting cookies from the site for further work.
I used the following constructs (for SQL Ahywhere 12.0.1 and 16.0):
create or replace procedure "dba"."fa_cookies"(
"urlSpec" long varchar,
"certif " long varchar )
url '!urlSpec'
type 'HTTP:POST:text/plain'
certificate '!certif'
set 'REDIR (COUNT = 0)'
header 'X-Requested-With: X-Requested-With';
...
insert
into web_results
select *
from "dba"."fa_cookies"(@urlSpec,@certif)
with ( "attribute" long varchar, "value" long varchar );
...
select "value" into @value
from web_results
where lower("attribute")='set-cookie';
...
However, for SQL Ahywhere 17.0.9, I get an exception. For example:
for SQL Anywhere Network Server Version 16.0 (User-Agent: SQLAnywhere/16.0.0.2754):
[connid = 1, 12/26 10:41:24.760, RESPONSE]
HTTP/1.1 302 Found
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: x-prototype-version,x-requested-with
Access-Control-Allow-Methods: GET,POST,OPTIONS
Access-Control-Allow-Origin: *
Cache-control: no-cache="set-cookie"
Content-Type: text/plain
Date: Wed, 26 Dec 2018 07:41:40 GMT
Location: ...
p3p: CP="CAO PSA OUR"
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=0924DA43AAA4FFDADF636C29D930E840; Path=/; HttpOnly
Set-Cookie: AWSELB=8F27A917087250F091AC8F71E76AC3D9E7E728D4D8E2C0F1262262FE77BD4A99EEADD46879959010D4F134C3DCD0A903A0B8AA6E1F7BD75BB9AE0DEAE59C91BBF6DF5FCCCC;PATH=/;MAX-AGE=1800
Content-Length: 0
Connection: Close
[connid = 1, socket closed by peer]
[connid = 1, socket closed]
for SQL Anywhere Network Server Version 17.0.9 (User-Agent: SQLAnywhere/17.0.9.4913):
[connid = 20, [26/12/2018:10:05:14.489 0300], RESPONSE]
HTTP/1.1 302 Found
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: x-prototype-version,x-requested-with
Access-Control-Allow-Methods: GET,POST,OPTIONS
Access-Control-Allow-Origin: *
Cache-control: no-cache="set-cookie"
Content-Type: text/plain
Date: Wed, 26 Dec 2018 07:05:31 GMT
Location: ...
p3p: CP="CAO PSA OUR"
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=8C030B605E82C4D43C2ED58CFC57483C; Path=/; HttpOnly
Set-Cookie: AWSELB=8F27A917087250F091AC8F71E76AC3D9E7E728D4D8901F6A19976871D7B971EC231237E934420A2E6CB2A4E72C06F49CF0CD75C8F75952868417CDC62AA0D62B5A24055B2F;PATH=/;MAX-AGE=1800
Content-Length: 0
Connection: Close
[connid = 20, socket closed]
and EXCEPTION:
SQLCODE = -990, SQLSTATE = WW059, ERRORMSG() = The secure connection to the remote host failed: The connection was closed from the other side
Is this behavior of SQL Anywhere 17 a new feature?
Is it possible to avoid this exceptions for SQL Anywhere 17?
asked
26 Dec '18, 03:02
Ilia63
1.2k●49●55●78
accept rate:
44%
Can you show us the exact SQL statement that raised the exception?
As the web server returns two Set-Cookie headers, it may (or may not!) have to do with changes introduces with 17.0.4.2000:
See the changes documented for multiple headers with the same name.
That's a very wild guess, another one is the newly introduced EXCEPTIONS option for the CREATE PROCEDURE statement documented on the same page.
In my understanding, the "SELECT value INTO @value" statement should fail when there are more than one rows fitting the WHERE clause...
I apologize for the delay in replying.
Let:
ASA16:
ASA17:
Unfortunately,
did not help get rid of the error.
or in SELECT: also does not help.Using the third output attribute ("Instance") in RESULT:
I assume that an empty response body causes this error.
ps I apologize for the delay in replying.
Well, according to the web log snippets from your question, it seems that both versions receive similar responses from the server, so I'm not sure why the web procedures do not behave identically...:(
Is there any difference in the request they generate (also visible in the web log output)?
Yes, both versions get the same responds. Except for the end of zoc-file.
ASA16:
ASA17:
And what about the requests (not the responses)? Do they differ?
ASA16:
ASA17:
andWell, I hope Graeme or other SQL Anywhere engineers have a clue, I don't have one...
Thanks (((
I'm afraid I'm unable to reproduce this behaviour here. Would it be possible for me to test against your HTTPS server? If that's OK, can you email me (myfirstname.mylastname @ sap.com) the root certificate (i.e. 1stA_root_20200625.crt)?