Well, Im connecting to a server generated page


I do everything right in sockets (I think)
But I get this error:

Is there some way I can view the source instead of the server info?


Bear

Heres my code (a few urls wiped out, but its not illeal, dont worry)

Code:


When the right urls are inplace, it gives me that message aboveIs it the server, and is there anyway to view the source?

Open the site in a browser and right click and choose View Source (if in IR... if in something else, it'll probably be in a View menu). Use this to view the source until you get the connection figured out.

As far as giving you help, without having the site name to test out, no one will be able to do much for you. Looks like it may be a problem with cookies needing to be sent.

Without seeing the URL's I can't really test it.

Minor additions..

1. You don't need to set a var, sockread %<Var> stores the data already.
2. You have one too many } braces.
3. Maybe you should use Khaled's on Sockread example from the help file. It's alot cleaner.
4. Paste the code with the URL and page to GET.

He's declaring the local variable so that it is destroyed when the script finishes.

Only specifying "sockread %var" will make that a global variable, which is left in the variables list.

Ah right, didn't realise. I sit corrected.

I can see a few mistakes, and some things you might want to take into consideration.

;Im just trying to view the source here
/echo -a %temp
change to
/echo -a $iif(%temp,$v1,-)
becuase %temp can be nothing sometimes, however I dont think this would stop the script for good.


sockwrite -n $sockname Host: http://www.***host***.com $+ $crlf $+ $crlf
sockwrite -n $sockname Connection: Keep-Alive
change to
sockwrite -n $sockname Connection: Keep-Alive
sockwrite -n $sockname Host: http://www.***host***.com $+ $crlf $+ $crlf
becuase your ment to end with a nul line not have stuff after it, not that this should do anything to stop it either.
actually you dont even need "sockwrite -n $sockname Connection: Keep-Alive" (normally)


If after all that the page dont come up as you expect then its likely this
Set-Cookie: SITESERVER=ID=c48189ec1b36b646554cb46c5fb57378; expires=Monday, 01-Jan-2035 00:00:00 GMT; path=/; domain=.***webpage***.com
Set-Cookie: ASPSESSIONIDQATDBSTC=IDJJACKDGHIKJMIOOJJLPMDE; path=/

where you have
sockwrite -n $sockname Host: http://www.***host***.com $+ $crlf $+ $crlf
try changing to
sockwrite -n $sockname Cookie: SITESERVER=ID=c48189ec1b36b646554cb46c5fb57378; expires=Monday, 01-Jan-2035 00:00:00 GMT; path=/; domain=.***webpage***.com; ASPSESSIONIDQATDBSTC=IDJJACKDGHIKJMIOOJJLPMDE
sockwrite -n $sockname Host: http://www.***host***.com $+ $crlf $+ $crlf

If that doesnt work, you have to do a two pass system hitting the first time to get the two Set-Cookie:lines and combine them into one Cookie: line then send that with your second attempt.

See this for some ideas on that.

Usually, you can't return the exact same cookie data because the as it passes through the browser, it is changed. To get valid cookie information to return to the site, you need to look at the http header information being sent by the browser itself. In this case, it is different information that needs to be returned.

Also, you don't return the expiration information... only the actual siteserver id and session id information.

And, finally, you return Cookie information with Cookie, not Set-Cookie (that's the command when the information is sent to you).

I did give him the information in private, so we'll see if it works for him.

When does it do that, or are you meaning local scriptings making a change?



Without the site to check its pretty hard to go by anything more than what was given, I had tro go with the information at hand. Oh and I very much doubt the the site cares less if someone returns the expirery date. I didnt mention it basicly becuase (1) it would have been an extra layer of complexity removing things, and (2) I wasnt sure if it was just an expiry, again this comes to the problem of not been told the actual site.



Thanks ill remeber that, oh wait thats just what i said <snicker snicker>

PS: Why keep it in PM, show everyone, so more examples get posted.

Well, he brought it private because it's something which one would not want to share with hundreds of visitors due to content. Anyhow, I ran the site through a http header viewer plugin and came up with the appropriate cookie information and it is indeed different from what was sent by the site. Note that if you reload a site, each time you do, it will send a unique cookie encoding to you, but you will always send the same cookie information as a response back to the site.

I agree that it's hard without knowing the site... that's what I originally said and why it was brought to PM to me.

This is the correct cookie reply line:

Cookie: SITESERVER=ID=5467fee8d18e08d81b4a8c8c2fbf8025; ASPSESSIONIDQATDBSTC=GOBABCKDGCNBFPKLPKELJJCB