Strange idea: after seeing how the Debugger dispays the InternetHeaders, I wanted to do the same (in a Listbox).
All I was able to do is:
[code] Dim MySocket As New HTTPSocket
Dim MyHeaders As InternetHeaders
Dim The_Source As String
MyHeaders = MySocket.GetHeaders(MyURL + "/", 30)
The_Source = DefineEncoding(MyHeaders.Source, Encodings.UTF8)
TA.Text = The_Source[/code]
Good start: it shows me both the Key and the Value, but not how to separate the former from the later
Clues ?
Find the position of the first : on each line and use Left and Mid to extract the key and value parts.
Thanks Greg
The LR talks about colon separated entries, but this is not always the case or a case for error(s) and that is why I asked the question here. Heres what I got for your avatar photo:
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 01 Mar 2017 12:21:30 GMT
Content-Type: image/jpeg
Content-Length: 4529
Connection: close
Last-Modified: Mon, 31 Oct 2016 20:13:33 GMT
Link: <https://www.gravatar.com/avatar/d866da881b9e0b9f84df15b8ab35a986?d=identicon&s=130/>; rel="canonical"
Content-Disposition: inline; filename="d866da881b9e0b9f84df15b8ab35a986.jpeg"
Access-Control-Allow-Origin: *
X-nc: MISS fra 4
Accept-Ranges: bytes
Expires: Wed, 01 Mar 2017 12:26:30 GMT
Cache-Control: max-age=300
Source-Age: 0
The Headers Types can be far different from an object to the other(s) / its location (line number) too, etc.
In a current project where I download stuff from a specific web server, I assume that Content-Disposition holds the object file name (and it seems to be true at usage on that target location) as well as the Content-Length
but I do not always get it), Content-Type have the item mime
In an old (very old) project, I saved in a Log history file the InternetHeaders contents, as is; I think I know why.
If I follow the docs, for example, for the Server type, I can use NthField
, but not for Date.
Don’t make assumptions about the existence of http headers and what they contain. Content-Length may not exist depending on the protocol.
If you want to know, go look at the RFCs for http 1.0 (old sockets) and http 1.1 and 1.2 for the new sockets. There’s a lot of things that must be done a certain way and others that should be. How it’s actually implemented if usually up to the person reviewing the document in the end.
The InternetHeaders object works like a dictionary though. You should be able to pull out the key-value pairs fairly easily.
Thanks Greg for your answers.
That was my first idea, assumption, but since I do not found any clue in the docs I asked here how to do.
I will explorate after a nap
my eyes are full of sand 
I was just looking in to getting the response headers, using the Xojo.Net.HTTPSocket class, but it seems that the headers are not exposed to us… 2016r4.1
shao:
did you check this page: http://developer.xojo.com/xojo-net-httpsocket ?
(RequestHeader).
or: http://documentation.xojo.com/index.php/InternetHeaders
(Classic)
I forgot to mention:
Xojo 2015r1
El Capitan 10.11.6
PS: the nap was gooood !
I start to use:
site:developer.xojo.com InternetHeaders
when I search someting @ developer.xojo.com/ I get faster results 
Emile, indeed I did… and that is handy if you know what headers there are, but there is no way to get a dump of the headers returned…
If you compare the original HTTPSocket class’ HeadersReceived event HTTPSocket.HeadersReceived ( Headers as InternetHeaders, HTTPStatus as Integer ) you can see that the headers are returned and you can do what you need to do…
In the new Xojo.Net.HTTPSocket class, the HeadersReceived event no longer has the headers parameter HeadersReceived(URL As Text, HTTPStatus As Integer) so you will need to know exactly what the server is returning and hope that nothing changes…
And if you look at Norman’s reply in this thread https://forum.xojo.com/27488-how-to-list-response-headers-in-xojo-net-httpsocket you will see his comment about the headers [quote]As for why its not exposed yet - because its not exposed yet[/quote]
Annoying answer for youngsters, stupid answer for oldster: they may die befor it will be exposed.
or 
(depends on the category you are in: youngsters or oldsters ).
Even if they would just give us access to the headers, as a memory block or Text, and then we can do whatever we want with it… That would be a good solution and not really require much work on their part (less work then having to re-write the headers or convert to InternetHeaders)