-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
digiline NIC crash #539
Comments
interesting, the request itself should not crash the server.. 🤔 |
Hmm, this Lua controller saves and reads data to my Webserver. I have multiple of them so they will sync automatically the coordinates for the jumpdrives but it never caused a crash and I also wasn't online the last time. Were there any changes to the mod or maybe to the minetest release? |
Not that i'm aware of 🤷 there might be more details in the log files, i'll check them later today, thanks for the reply 👍 |
disabled the NIC until i can replicate/solve that issue, i hope nothing breaks because of the unknown node 😓 |
Could also just override NIC functionality with noop() via pandorabox customizations to keep nodes in world but functionality disabled. minetest.override_item("digistuff:nic",{ digiline = { receptor = {}, effector = {} } }) |
I was in a hurry, commenting out from EDIT: there were no additional infos in the debug logs, i have no idea how to reproduce this |
sorry for that.. misclicked.. Actually I was thinking could this be just bad luck and server just caused segfault for whatever another reason and nic errors just happened to be there just before it... of course very hard to say for sure without any backtrace. |
I thought that too at first but there were no segfaults 😕 |
So I did some testing with the code I copied, and I was able to recreate the error, but it didn't crash, I just got the errors in chat 😕 I have the full code if you want it (all 251 lines of it), but this is all I needed to produce the errors: (note the single space after digiline_send("nic", "https://subgames.minetest.land/r.php?pw= ") It seems that the cause of the problem is that the NIC doesn't filter spaces, and just leaves them as is when sending the request, because any text after It still doesn't explain why it crashed though, I might try it on the test server to see if it crashes there... EDIT: no crashes on test server 😕 |
I changed the override in |
@OgelGames should there now also be guard against msg that is not string? gsub probably wont like tables for example |
Yes there should, totally forgot about that... EDIT: done: pandorabox-io/pandorabox_custom@3916c3b |
Just in case I did ran simple test, tried to feed some weird url characters: local http = minetest.request_http_api()
local function t(msg)
http.fetch(
{url = msg,timeout = 1,user_agent = "Minetest Digilines Modem",},
function(res)
print(string.format("Result: %s", dump(res.code)))
end
)
end
minetest.after(3, function()
for i=0,255,1 do
for j=0,255,1 do
t("http://127.0.0.1/" .. string.char(i) .. " " .. string.char(j))
end
end
end) At least this did not crash. Some codes were zero instead of valid HTTP status, didnt check but pretty sure http.fetch refused to handle some control chracters and returned zero code instead. |
Hmm... Maybe the http api should be the one checking for spaces, because spaces should never be in a url... |
You should then build complete list of https://tools.ietf.org/html/rfc3986#section-2.2
So, all characters above must be left as is in HTTP API and user should handle encoding if those are not used as delimiters.
Not sure if HTTP API should handle any urlencoding, it would enforce correct syntax if done for limited set of characters but it will be impossible to make correct decisions when reserved characters should be encoded and when those should not be encoded. Should API then do any of that or leave all encoding for user (digistuff:nic code) to do? I think encoding some and leaving some unencoded would make HTTP API too complex and would also require a lot more documentation + user must then make sure that double encoding wont happen. Possible problem if HTTP API fails when called with URI that is invalid by RFC spec but handled correctly by (insert service here). Should probably dive a bit deeper into most important use cases to start making But here I think digistuff:nic as limited application using HTTP API could handle encoding for some special characters or clean up / refuse to pass URLs containing some characters to http.fetch. Multiple choices, not sure what would be best. If |
NIC / HTTP API seems to send spaces and many other characters as is, many web servers will return HTTP 400 but this for example kinda works when requesting URL printf 'HTTP/1.1 200 OK\n\nHelloWorld' | sudo nc -l 80 Results from http.fetch: {
succeeded = false,
code = 200,
completed = true,
timeout = true,
data = "HelloWorld"
} Note NIC seems to work correctly fulfilling user request and also responds with actual error code returned from actual web server (one that wont handle spaces in URL):
This causes error message to be visible in logs but that should not make any real harm, not sure if this actually should be logged as error. Warning would make more sense for me as this is still completely normal and correct response:
I don't think anything should be changed in HTTP API itself, it does what user requests and seems to handle it correctly. Would need to dive into actual HTTP API implementation to test this case. What it tries to do with response and is there something (in code) that could explain crash when response contains some weird stuff. edit. just for completeness here's also raw request sent by NIC when URL contains "invalid" character (space):
|
EDIT: found what was causing it, it was this code in a Lua controller connected to an NIC: (there is actually a lot more, but this is the bit that is causing the crashes:
The text was updated successfully, but these errors were encountered: