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
Find the position of the first : on each line and use Left and Mid to extract the key and value parts.
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
Date: Wed, 01 Mar 2017 12:21:30 GMT
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"
X-nc: MISS fra 4
Expires: Wed, 01 Mar 2017 12:26:30 GMT
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
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
, but not for
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
did you check this page: http://developer.xojo.com/xojo-net-httpsocket ?
I forgot to mention:
El Capitan 10.11.6
PS: the nap was
I start to use:
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)