Implements redirects

[Tieske]

Fixes #34, but depends on a PR for LuaSocket (lunarmodules/luasocket#133) to export more information.

With this PR the https.request method will work for both http and https calls and allow redirects (also for changing schemes; http <-> https, in the redirect).

By default it will not allow https -> http redirect, and fail with a security error in that case; Unallowed insecure redirect https to http. If the redirect field in the request is set to "all", then the redirect https -> http will be allowed and executed.

Some simple test code;

local https = require("ssl.https")

local function doreq(url)
  local reqt = {
      url = url,
      --redirect = "all",     --> allows https-> http redirect
      target = {},
  }
  reqt.sink = ltn12.sink.table(reqt.target)

  local result, code, headers, status = https.request(reqt)
  print("Fetching:",url,"==>",code, status)
  if headers then
    print("HEADERS")
    for k,v in pairs(headers) do print("",k,v) end
  end
  return result, code, headers, status
end

--local result, code, headers, status = doreq("http://goo.gl/UBCUc5")   -- http --> https redirect
local result, code, headers, status = doreq("https://goo.gl/UBCUc5")  -- https --> https redirect
--local result, code, headers, status = doreq("https://goo.gl/tBfqNu")  -- https --> http security test case

[brunoos]

And will wel make backward compatibility?

I think someone could create a third project that is aware of LuaSocket and LuaSec, with the "net tools".

The "net tools" project could do a best work with http/s, imap/s, smpt/s, etc, without restrictions.

Eventually, LuaSocket and LuaSec could remove these tools from the base and concentrate only in low-level communication.

[Tieske]

And will wel make backward compatibility?

Yes.

I think someone could create a third project that is aware of LuaSocket and LuaSec, with the "net tools".
The "net tools" project could do a best work with http/s, imap/s, smpt/s, etc, without restrictions.
Eventually, LuaSocket and LuaSec could remove these tools from the base and concentrate only in low-level communication.

That could work, but currently LuaSec builds on top of LuaSocket, LuaSocket does in no way depend on any other module. If these functions where extracted into a separate module, then that module would depend on both LuaSocket and LuaSec. So the current LuaSocket functionality would get an extra dependency on LuaSec in that scenario. So I don't see that happening. Especially considering the slow pace of development of LuaSocket.

But -back to this PR- that also limits the chance of this PR ever getting merged, as it depends on a PR for LuaSocket as well. As such I included the full http.lua file from LuaSocket in an update of Copas that I'm working on, because I cannot wait for LuaSocket. So maybe we can do the same for LuaSec, and cut the dependency on the socket/http.lua module. Let me know whether you're inclined to accept that, then I'll create a new PR based on that.

[Lord-Helmchen]

@Tieske Could you update this (and lunarmodules/luasocket#133 ) to current master?

I'm having 301 troubles, strongly suspect that url rewrites are the cause (urls with ' and similar fail, others work fine; I don't see a difference between the originally requested url and the one in the 301 reply) and dearly hope this will resolve them...

[ewestbrook]

Obviated by LuaSocket#268.