"tsnet (1) Received HTTP/0.9 when not allowed"?

[Richard Gaskin]

Good morning, Charles -

Thank you for your assistance, and your offer to look into it.

TL/DR:

As work progresses I'm increasingly convinced this isn't a client-side 
issue at all, but a side-effect of how LC Server's insistence on loading 
fonts that aren't needed triggers some host's CGI resource constraints.

The tsNet part of this fits that hypothesis: the HTTP version assumption 
is happening because the data coming back is literally 0 length - 
there's nothing there, fitting a pattern I've seen before on this host 
when CGIs are cut off.

At the moment I think I have a handle on the situation, and a plan for 
addressing it.  If I'm going to take advantage of your expertise let me 
queue up those points for when I truly need them. :)



More complete:

I found that this was only happening when two calls are made to the 
server within a short span of time, usually when first downloading a 
stack and then the stack requests the data it uses to display for the user.

Simply putting a pause of just under 2 secs between the stack download 
and its request for data has at least allowed users to get back to work.

I'm reluctant to pester DH support for more details on how their 
resource constraints are so frequently triggered by LC Server because I 
became familiar with the issue after spending weeks with them diagnosing 
an issue a few years ago, and I don't want them to think of LC as a 
problem and ban it altogether.

Part of what I learned from that experience was a workaround Mark 
Waddingham and Peter Brett came up with, essentially tricking LC Server 
into using a local folder with just one font instead of the whole set of 
system fonts.  Where I've used that workaround on Dreamhost everything's 
run well (indeed LiveCodeJournal.com uses it for every page and its 
performance is indistinguishable from static pages).

For myself, I have other reasons to migrate the app to a VPS, and we're 
provisioning one soon. Shared hosting is great for low-value low-traffic 
stuff, but with VPSes priced on par these days it's the better choice 
when predictable loads are useful.

My LiveCode, the language is so well suited for server work (chunk 
expression make short work of most of what we do on servers), it's a 
shame to see LC's performance and sometimes reputation take a hit by a 
loading sequence that favors initializing fonts that are never used by 
99+% of scripts.  Hopefully one day BZ#14115 will be addressed, and LC 
can be used with all the beautiful efficiency it's capable of.

DH is a popular host, and I've seen this occasionally on at least one 
other shared hosting company before using the workaround.  So this isn't 
just a Dreamhost issue, and may show itself at just about any time on 
perhaps any shared host that's successful enough to have resource 
constraints.

In the meantime, for those who enjoy server admin there are always VPSes.

-- 
  Richard Gaskin
  Fourth World Systems



Charles Warwick wrote:
> Hi Richard,
> 
> The curl version that is used in tsNet is regularly updated.  The latest version of tsNet is using curl 7.74.0.
> 
> My understanding of that particular issue is that if the first data line that is received back from the HTTP server doesn't match an appropriate response, it will assume HTTP/0.9.
> 
> Is there a test URL you can post that shows this problem so I can see what is coming back from the server?  Can you post what you are getting in the libURL debug?
> 
> Also, have you tried a version of LC that has a different version of tsNet included - just in case this happens to be a new bug in the curl library.
> 
> Thanks,
> 
> Charles
> 
>> On 1 Apr 2021, at 10:37 am, Richard Gaskin wrote:
>> 
>> Matthias wrote:
>> 
>>> was there a change in the configuration of your web server recently?
>>> Is your web service using php or LC server?
>> 
>> LC Server.  Hosting likely had changes, since this app has been in production for a long time without issue.
>> 
>> I believe the change most significant here is business success: Dreamhost apparently has a lot of customers and runs pretty packed shared servers  these days (reason #48 why I prefer VPSes). I'm guessing part of this is a noisy neighbor problem.
>> 
>> But I'd guess at least some of this is the interaction between Dreamhost's resource quotas and LC's wasteful boot process, in which most of the resources it consumes are for font init that I'd guess 99.9% of server scripts never need:
>> https://quality.livecode.com/show_bug.cgi?id=14115
>> 
>> Another contributing factor may be the curl version tsNet has embedded. Some of the discussions I came across reference older curl versions that assume HTTP 0.9 by default and misreport that under certain error conditions if header info isn't parsed just so.
>> 
>> Is tsNet's curl version documented somewhere?
>> Does LC keep tsNet updated with the latest curl with each release?
>> 
>> 
>>> I am not sure if this is of help, but there is a debug stack
>>> available for tsNET. Maybe the debug information gives you
>>> some more information.
>>> https://downloads.techstrategies.com.au/tsnet/debug_liburl.livecode
>> 
>> Thanks.  It's using libURLSetStatusCallback and libURLSetLogField, so it's more or less like the one I'd already built into my tooling.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> ____________________________________________________________________
>> Ambassador at FourthWorld.com                http://www.FourthWorld.com
>>