HTTP() callback won't fire, + server crash using HTTP()

HTTP() callback won't fire, + server crash using HTTP() - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP (https://sampforum.blast.hk/forumdisplay.php?fid=3)
+--- Forum: Bug Reports (https://sampforum.blast.hk/forumdisplay.php?fid=20)
+--- Thread: HTTP() callback won't fire, + server crash using HTTP() (/showthread.php?tid=303055)

HTTP() callback won't fire, + server crash using HTTP() - KoczkaHUN - 11.12.2011

Bug 1:
Callback specified in HTTP will not be called if data[] exceeds a size limit (maybe 4096?)
Example script to reproduce:

pawn Код:

#include <a_samp>
#include <a_http>

public OnFilterScriptInit()
{
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "LolCallBack");
}

forward LolCallBack(index, response_code, data[]);
public LolCallBack(index, response_code, data[])
{
    print("callback fired");
    printf("IDX %d, response_code %d, data size = %d", index, response_code, strlen(data));
    return 1;
}

Bug 2:
HTTP() request makes index "stuck", and an other HTTP call to that index will crash the server:
Steps to reproduce:
- Compile the filterscript shown in Bug 1
- Load the filterscript
- Reload the filterscript with reloadfs
- Server crashes

Re: HTTP() callback won't fire, + server crash using HTTP() - wups - 13.12.2011

Similar:
https://sampforum.blast.hk/showthread.php?tid=302994

Re: HTTP() callback won't fire, + server crash using HTTP() - Calgon - 13.12.2011

"Bug 1" was made that way IIRC, so it's not really a bug.

You can bypass it by creating a PHP script to parse a web page for you and to grab only the necessary contents and then use HTTP()'s data string to retrieve the parsed content.

Re: HTTP() callback won't fire, + server crash using HTTP() - leong124 - 13.12.2011

Bug 2 is unrelated to the HTTP function. If you reload some filterscripts using reloadfs in the server console several times, the server will crash.

Re: HTTP() callback won't fire, + server crash using HTTP() - KoczkaHUN - 13.12.2011

Quote:

Originally Posted by leong124

Bug 2 is unrelated to the HTTP function. If you reload some filterscripts using reloadfs in the server console several times, the server will crash.

Yes, it is related to the HTTP function.
You can achieve the same by doing this [notice that we use the same ID]:

pawn Код:

forward _crash(index, response_code, data[]); public _crash(index, response_code, data[]) return 1;
stock crash()
{
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "_crash");
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "_crash");
}

And call crash(). This bug is not associated with reloadfs at all.

Re: HTTP() callback won't fire, + server crash using HTTP() - TopSecret - 13.12.2011

This is because data is too long and exceeds heap size (strings/arrays passed to publics are allocated on AMX heap) causing heap/stack collision. Try increasing heap size with #pragma dynamic.

pawn Код:

#include <a_samp>
#include <a_http>

#pragma dynamic 100000

public OnFilterScriptInit() {
    crash();
}

forward _crash(index, response_code, data[]); public _crash(index, response_code, data[]) return 1;
stock crash()
{
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "_crash");
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "_crash");
}

Re: HTTP() callback won't fire, + server crash using HTTP() - leong124 - 14.12.2011

Quote:

Originally Posted by KoczkaHUN

Yes, it is related to the HTTP function.
You can achieve the same by doing this [notice that we use the same ID]:

pawn Код:

forward _crash(index, response_code, data[]); public _crash(index, response_code, data[]) return 1;
stock crash()
{
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "_crash");
    HTTP(4, HTTP_GET, "www.******.com/?q=a", "", "_crash");
}

And call crash(). This bug is not associated with reloadfs at all.

Confirmed, it crash the server no matter if the ID is the same or not. However, I don't think that's a valid searching link. It requires some more code so as to prevent people from stealing its search results. Also, the returned page isn't plain text. I don't think you can get the required data.