As the title says... Chat on...

User avatar
By JOHN_T
#60576 Thanks! Pointed me in the right direction. See below for examples that work & don't work when listening on port 81. I still have some more testing to do but I presume Chrome is demanding it sees the response code "HTTP/1.0 200 OK" and I was not sending it...

The link you provided works fine on port 81 ie. This webserver code works:
-- a simple HTTP server
srv = net.createServer(net.TCP)
srv:listen(81, function(conn)
conn:on("receive", function(sck, payload)
print(payload)
sck:send("HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n<h1> Hello, NodeMCU.</h1>")
end)
conn:on("sent", function(sck) sck:close() end)
end)



But this code does NOT work when listening on port 81. It is from the NodeMCU net.createserver documentation and is what I based my code on :-( haha
-- server listens on 81, if data received, print data to console and send "hello world" back to caller
-- 30s time out for a inactive client
sv = net.createServer(net.TCP, 30)

function receiver(sck, data)
print(data)
sck:close()
end

if sv then
sv:listen(81, function(conn)
conn:on("receive", receiver)
conn:send("hello world")
end)
end
User avatar
By marcelstoer
#60610
JOHN_T wrote:I presume Chrome is demanding it sees the response code "HTTP/1.0 200 OK"


Not necessarily this exact string but it's safe to assume that the browser needs any indication of what protocol the server who sends a response to it talks. After all it needs to to know how to interpret the data. This can be HTTP 1.0, HTTP 1.1, HTTP/2, or FTP or...
Every browser is different in how it behaves if that crucial piece of information is missing. So it might be that the browser from vendor X in version n automatically assumes HTTP if the server doesn't tell if you connect to one of the two standard web ports 80/443. The behavior may be different for the same browser in version n+1 or for connections to different ports.

To conclude I'd argue that the absolute minimum is "HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n" to rule out any misunderstanding between your device/server and the browser. Of course "200 OK" may be replaced by a different status code and the content type should be adjusted if your not sending HTML (e.g. to text/plain).
User avatar
By JOHN_T
#60620 Thanks again. I know little about html and browsers but it makes sense to let the browser know the protocol instead of assuming. Even having the URL specify http protocol eg. http://10.1.1.243:81 didn't work.

When looking at the received header info in Chrome, and using default port 80, I saw status code 200 OK and I wrongly assumed this header information was being sent by NodeMCU - my bad, now I realise NodeMCU is acting as a TCP server not necessarily a http server. It looks like Chrome fakes/adds this information when connecting to http on default port 80


I can confirm details in the previous post is what is needed. I changed the send buffer initialisation line local buf="" to the following and Chrome now works fine. The rest of the HTML code is not pretty but works OK to give me a full-screen table that refreshes every second.

local buf = "HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n"
buf=buf.."<!DOCTYPE html>\r\n<META HTTP-EQUIV=\"REFRESH\" CONTENT=\"1\">\r\n"
buf=buf.."<html style=\"height:100%;padding:0;margin:0\">\r\n"
buf=buf.."<body style=\"height:99%;width:100%;padding:0;margin:0\">\r\n"
buf=buf.."<table style=\"height:99%;width:100%\">\r\n"
.... other code to complete filling the buffer with html and finally send it ...
User avatar
By marcelstoer
#60621 Good to know you got it fixed. Hope you're having fun with NodeMCU :)

If you're sending back a lot of data (i.e. your buffer will be large) look at http://nodemcu.readthedocs.io/en/latest ... socketsend for how to do that "properly".

proper = event-driven and non-blocking