handling of "HTTP/1.1 :00 :00"

Posted by sjellin.dovetail on 17-Sep-2018 10:37

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 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.

All Replies

Posted by bronco on 17-Sep-2018 12:33

The specs (RFC 2616 section 6, see: [View:]) 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 :-)

Posted by Peter Judge on 17-Sep-2018 15:10

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 ( 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.

Posted by onnodehaan on 17-Sep-2018 15:24

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

Posted by Peter Judge on 17-Sep-2018 15:36

Hey Onno,
That’s an option too, and possible with some changes. The bit to think about would be the level at which the callbacks need to be at (so as not to slow the whole read-the-incoming-message loop down).
Currently you’d have to customise the existing writer – this is one of the few places in the HTTP that’s not plug-and-play (although it does implement an interface so not all is lost :).

Posted by bronco on 18-Sep-2018 04:47

<kidding>Maybe they should be able to inject the status line parser</kidding>

Posted by Peter Judge on 18-Sep-2018 09:58

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.

Posted by on 18-Sep-2018 10:20

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 :)

Not that is anything wrong with DI in general but there seems to be quite a few injectors for a simple thing like a HTTP client ;)

Marian Edu

Acorn IT 
+40 740 036 212

Posted by Peter Judge on 18-Sep-2018 10:46

There are.  I find them very useful for being able to extend stuff, both internally (component dev) and externally (customers/consumers thereof).
This is a decent example of when it would have been good to say : “replace the default response writer with my version that knows about :00 status codes”.
I am generally a fan of DI – it falls into the “single responsibility” area for me.

Posted by onnodehaan on 18-Sep-2018 14:52


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.

This thread is closed