Hi All,
(Tried in 11.6, Unix).
I am trying to convince a client to fix their lack of status code reply, but unfortunately curl -w "%{http_code}" and some other tools just decide that :00 means status 200. Funnily enough curl -i shows that the raw reply is :00. Also tried in postman and it also just decides to return 200.
On the OpenEdge.net.pl log output i also see the :00 status code. The issue is that just making the call causes the 4gl to give the following error ** Invalid character in numeric input :. (76). I could catch the invalid character exception but that feels like looking for trouble.
Is this something that works in 11.7 ? (I can't access the url from the 11.7 environment i have) - or is there some magic setting that can be used to override the status to 200 without a catch block ?
This seems like a 200 should be almost a default if utilities like curl etc just happily return a 200 when explicitly asked to return the value.
The specs (RFC 2616 section 6, see: [View:https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html:550:50]) are pretty clear about it:
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.
The fact that curl plays nice with non-integer status codes is no excuse to do it right or expect other clients (the 4GL in this case) to understand the same non-standard responses. But hey, I don't have to deal with your client :-)
As Bronco notes, the HTTP spec indicates an integer should be used. The HTTP client has the same assumption, as you can see in the IHttpResponse (github.com/.../IHttpResponse.cls) interface's StatusCode property.
While servers (and clients) can be extremely lax about implementing the spec, I'm not sure there there should be a fix for this (or what).
We could default to 200/OK but if there's any (other) junk in the response for any reason, would you want a signal that everything is OK?
We could default to 000/ and parse the message as best as we can.
I'm more inclined to the latter but am still not convinced. Appropriate status codes are a fundamental part of the HTTP spec.
Hi Peter,
Probably a bad idea, but if you would like to alter something to allow for non-standard HTTP-code, why not add support over overriding the piece of code that interprets the response and makes it an integer?
That way edge-cases can be coded without you guys havnig to make defaults quesses
<kidding>Maybe they should be able to inject the status line parser</kidding>
That's the issue - there is no "Status line parser" , just a "incoming message parser", that deals with the status line, the headers and the entity (body).
Kidding aside, i'd probably look to add injection of the whole message parser first and see if that solves peoples' problems.
Or you can just catch that error and let status code set to unknown, maybe add a new property `status line` on the web response... after all there are only 3 pieces of information there :)
Marian
I've never run into a problem with too much options to extent but a lot of times into problems when I couldn't extent stuff.
The fun thing about extending is that you can cope with situations that where not originally envisioned by the creator of the original functionalit.