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

Thu Apr 1 14:38:23 EDT 2021

Richard,

I also have a problem when requests come too fast. This might be related? I'm on an on-rev server. My problem was that using sessions caused the LC server to choke about 50% of the time when sending back-to-back requests. I confirmed this when stress testing by sending 2 or more requests to LC server from the from the QCC demo client stack back-to-back. I'm wondering if these two are connected? https://quality.livecode.com/show_bug.cgi?id=22560
I want to use LC Server sessions for some website work but am reluctant to do so because if 2 users happen to hit the server too close together then LC server locks up for any future requests that uses sessions. If you find a solution I'll be interested to see if it helps me also. 

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode
Sent: Thursday, April 01, 2021 1:59 PM
To: use-livecode at lists.runrev.com
Cc: Richard Gaskin
Subject: Re: "tsnet (1) Received HTTP/0.9 when not allowed"?

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

_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode