If needs be, could someone mark Feedback Case #54361 as Pre-release/beta as its not an option when putting in a feature request? Thanks

From the feature request:

With the upcoming release of the new URLConnection could we have a way to iterate through all the ResponseHeaders that have been returned to us? We have a Method, ResponseHeader(name As String) but we have no way to know what has been returned for us to look it up unless we know before hand.

As this is seemingly going to be a replacement for Xojo.Net.HTTPSocket in the long run, it seems like an opportune time to add a feature that has been requested in Xojo.Net.HTTPSocket since April 2017 Case 47895.

Thanks!

I threw some of my Top Cases points at this one. Not having these headers available to iterate through in the Xojo.Net.HTTPSocket caused me some grief recently.

This is a real pain in iOS apps with Xojo.net.httpsocket

Julian, I added your case to my #1 top case for what it's worth

@Julian S since April 2017 Case 47895.

+1

it is good to have HTTP 1.1+, but why loose functionality, in the old HTTPSocket Xojo had a internetHeaders property as a dictionary.

Totally agree. Ran into this issue recently too.

Also when two Julians suggest a feature request I think it should count for 2X points.

I add my points too.

I've moved this to General as 2018r4 has been released.

Hi everyone!, just getting started on a Xojo project. I'm consuming an API that I need to grab the values of a couple headers that are returned in a Get along with the body response body which will return a JSON payload. While it would be great to have the headers in a dictionary as discussed above, at the moment, I'd be happy just getting a value out of a known header, such as 'X-Powered-By'. In reality I have some tracing headers I need to grab among other things.

Is this possible with the current shipping urlConnection? I see a Method: ResponseHeader but I'm not clear how to access it. This will be a console application use case on linux run on demand. I'd prefer not to shell out and use curl in this use case.

I see I can grab it using the Async method, anyway to do this using a sync call?

Yes, you can grab the headers by name: https://docs.xojo.com/URLConnection.ResponseHeader

Do not use the synchronous calls if you are designing API communication from the start. This is how you code yourself into a corner you can't get out of later. Last I heard synchronous calls were broken beyond usable in 18r4. However, if everything is operating as it should, it would seem from the documentation that you should be able to use the same method.

Could someone professionally explain to me what you're going to do with a header you weren't expecting if you were iterating through them? Nobody has been able to answer me this question with an answer that is reasonable or usable, and I'm actually very curious what kind of benefit this request has.

@Tim P Could someone professionally explain to me what you're going to do with a header you weren't expecting if you were iterating through them?

Off the top of my head:

1. Black box testing to see if an API returns the correct headers and list any you don't handle or know about.
2. Logging of schedules API calls so you can check back later what was returned by a server if a call failed.
3. Development of an API browser tool

@Tim P Yes, you can grab the headers by name: https://docs.xojo.com/URLConnection.ResponseHeader
...
Could someone professionally explain to me what you're going to do with a header you weren't expecting if you were iterating through them? Nobody has been able to answer me this question with an answer that is reasonable or usable, and I'm actually very curious what kind of benefit this request has.

HTTP message standards allow duplicate names, in order to provide multiple options to a particular key.
The order is important as this can change the semantics of the options.
Unless the Dictionary properly consolidates these options, certain settings could be applied wrong.

For example

Cache-Control: no-cache, no-store

is equivalent to (order is important)

Cache-Control: no-cache
Cache-Control: no-store

@John AKnight, Jr For example

Cache-Control: no-cache, no-store

is equivalent to (order is important)
Cache-Control: no-cache Cache-Control: no-store

I would expect in that case that Xojo is handling and passing me both when asked for Cache-Control, maintaining the order of importance.

@Tim P Could someone professionally explain to me what you're going to do with a header you weren't expecting if you were iterating through them? Nobody has been able to answer me this question with an answer that is reasonable or usable, and I'm actually very curious what kind of benefit this request has.

When I saw your post the first time I did not respond because i am not an IT 'professional' and may not have used the proper words, but I would have essentially said Julian's #1 response, particularly after the sync/async discussion. But being able to iterate though the headers sure as heck could be very useful to figure things out with a not well documented service!!!!

I think of coding relative to the vulcan philosophy of IDIC (Infinite Diversity in Infinite Combinations)... Just because you or I many to be able to envision how someone will use a feature does not mean it is not needed or valuable in specific situations... and when something is available some people ALWAYS creative and useful ways to use it.

- Karen

If an API isn't working as documented the vendor needs to fix it. You should never be guessing at an API. You can't create reliable software that way.

I know that I can't possibly imagine every use case for a feature, which is why I asked what people intend to do with the ability. However, I don't find any "guess and check" style answer to be reasonable (which is the only reason I wanted a "professional" response; I do not mean to exclude anyone personally, and welcome the discussion!)

Edit: I also find that people's "creative" uses of available API functions tend to be the source of their problems.

@Tim P If an API isn't working as documented the vendor needs to fix it. You should never be guessing at an API. You can't create reliable software that way.

Sometimes reverse engineering is the only way you can get to where you need to go. But then again I am trained as a physical scientist and figuring things out by experimentation and looking at and interpreting results is how I have made my living.

The quality of solutions with creative API uses depends on both degree of creativity and insight of the author , just like most other things, and will be highly variable.

- Karen

@Karen A I am trained as a physical scientist

Of course you need to reverse engineering in those filds, after all, you dont get the documentation from the creator :P

In software, the reverse engineering is needed when you have abandonware or when you are creating something similar, but, in this case, we are talking about a tool, it should be fully documented AND working as documented.

The creativity and insight of the author are very important, but, It makes no sense to waste time reverse engineering, guessing, puting lots of creativity and insight, if the tool is going to be fixed, or the undocumented behavior is gong to change or if the work arounds are not stable.

@Pedro I;Tellez Corella In software, the reverse engineering is needed when you have abandonware

Or when the documentation is not at the level needed or not available to you , too expensive or simply wrong....

The creativity and insight of the author are very important, but, It makes no sense to waste time reverse engineering, guessing, puting lots of creativity and insight, if the tool is going to be fixed, or the undocumented behavior is gong to change or if the work arounds are not stable.

Of course if the needed documentation is available to you, you most certainly should use it.

My point about creativity was more general than reverse engineering. It was about finding ways of using features in ways that logically and/or by the documentation SHOULD work that would to do things that would be more difficult or less efficient to do otherwise, but that usage never thought of/considered when the feature/API was created...

Being able to be creative and figuring things out myself to let me get things done, are what attracted me to coding. I guess that is part of why the deprecated Xojo framework felt like a straightjacket to me. It tried to constrain me to much...

- karen