Fix handing 302 redirect status

[nider]

Fix concatenation of incompatible types by expanding array elements

This fixes issue #3

[nider]

Well, I now actually read the issue properly as I'd been referred over here via a patch I submitted to a copy of this script that wasn't GitHub forked.

From my reading of the documentation of the http library in NSE (https://nmap.org/nsedoc/lib/http.html), it mentions for the function in question: "location - A numbered array of the locations of redirects that were followed."

My understanding of this when I read it was that the http library does follow multiple 302 redirects up to a certain point, and the redirect chain is available in the array. Further reading of the documentation affirms that the library definitely does follow redirects and allows the user to either adjust the number of times a redirect is followed or change the logic in how redirects are followed through providing an alternative closure.

In a specific run against a server I was testing against that uncovered the bug in the copy that I was using I got this result:

|_http-vuln-exchange_v2: Error 302 /owa/auth/errorFE.aspx?httpCode=500 -> /owa/auth/errorFE.aspx?httpCode=500 -> /owa/auth/errorFE.aspx?httpCode=500 -> /owa/auth/errorFE.aspx?httpCode=500 -> /owa/auth/errorFE.aspx?httpCode=500 -> /owa/auth/errorFE.aspx?httpCode=500

I had assumed from that array that the server was redirect looping on a 500 Internal Server Error; this however seems different to the circumstances mentioned by @at-AOCnet-CERT in the issue report where the server was redirecting to the configured FQDN. I'd be curious to see the full redirect chain from an example mentioned in the report.