Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
oh, I see…. Just catch up on the thread and saw the font loading issue. I can see how that becomes even more interesting to implement. > On 5 Apr 2021, at 01:00, Richard Gaskin via use-livecode > wrote: > > curl is reporting the default because the data it's receiving is zero length: > http://lists.runrev.com/pipermail/use-livecode/2021-April/264146.html > > -- > Richard Gaskin > Fourth World Systems > > > > Andre Garzia wrote:> Are you using the time travel external? HTTP/0.9 has > been historical for a long while, you can see more about this protocol at: >> https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0 >> <https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0> >> To what server you’re connecting? >>> On 31 Mar 2021, at 20:29, Richard Gaskin via use-livecode >> lists.runrev.com> wrote: >>> I have an LC app that recently started reporting this error when calling a >>> web service we wrote: >>> tsnet (1) Received HTTP/0.9 when not allowed >>> Searching around the web I see many varied descriptions of how one might >>> remedy that, but none seem to fit our circumstance. >>> Anyone else seen this? What was needed to resolve it? >>> -- >>> Richard Gaskin >>> Fourth World Systems > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
curl is reporting the default because the data it's receiving is zero length: http://lists.runrev.com/pipermail/use-livecode/2021-April/264146.html -- Richard Gaskin Fourth World Systems Andre Garzia wrote:> Are you using the time travel external? HTTP/0.9 has been historical for a long while, you can see more about this protocol at: https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0 <https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0> To what server you’re connecting? On 31 Mar 2021, at 20:29, Richard Gaskin via use-livecode wrote: I have an LC app that recently started reporting this error when calling a web service we wrote: tsnet (1) Received HTTP/0.9 when not allowed Searching around the web I see many varied descriptions of how one might remedy that, but none seem to fit our circumstance. Anyone else seen this? What was needed to resolve it? -- Richard Gaskin Fourth World Systems ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
On 4/4/21 4:36 AM, Andre Garzia via use-livecode wrote: Are you using the time travel external? HTTP/0.9 has been historical for a long while... Nonetheless, I believe 0.9 is still the lowest common denominator fallback mode when the actual level can't otherwise be determined. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
Are you using the time travel external? HTTP/0.9 has been historical for a long while, you can see more about this protocol at: https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0 <https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0> To what server you’re connecting? > On 31 Mar 2021, at 20:29, Richard Gaskin via use-livecode > wrote: > > I have an LC app that recently started reporting this error when calling a > web service we wrote: > > tsnet (1) Received HTTP/0.9 when not allowed > > > Searching around the web I see many varied descriptions of how one might > remedy that, but none seem to fit our circumstance. > > Anyone else seen this? What was needed to resolve it? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: "tsnet (1) Received HTTP/0.9 when not allowed"?
It is session specific. After 2 back-to-back requests to the LC server script that uses sessions 50% of the time you get into this state: 1) Any server request that attempts to create or use an existing session will lock up for 20-30 seconds and return empty. 2) Server requests that don't use sessions will continue to work. After you delete the lcsessions.idx file then all is back to normal until 2 or 3 requests using sessions come back-to-back. Very repeatable. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Thursday, April 01, 2021 4:59 PM To: use-livecode@lists.runrev.com Cc: Richard Gaskin Subject: Re: "tsnet (1) Received HTTP/0.9 when not allowed"? Ralph DiMola wrote: > 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 Thanks, Ralph. I do use persistent session data, but in this app I use a custom store, not LC Server's session handling. That's an interesting report, though, and I've added myself to the CC there. This loading-fonts-unnecessarily issue seems to be more related to my circumstance: https://quality.livecode.com/show_bug.cgi?id=14115 I'll know more if I get a chance I put the funky-font-fix workaround in place, but TBH I'm more likely to just move the app to a VPS instead. So it'll be a question of making the time for a funky setup test, and while that might narrow down root causes it won't fix anything since it's unlikely to be addressed anytime soon: two community members who've looked at the engine code believe IF-DEFing the font init would be prohibitively cumbersome given the imported subsystems that would need it (like Skia), and the core team has other priorities. > 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. How certain are you the issue you're seeing is specific to sessions? I've skimmed your report but haven't tested it, so forgive me if this should be obvious, but have you found any other circumstances where file I/0 may be the trigger, rather than session storage specifically? > If you find a solution I'll be interested to see > if it helps me also. If your issue is session-specific, I got nothing. If it may be general resource consumption (mostly memory), the funky-font-fix may do the trick. But setting it up is not for the feint of heart. If you're comfortable with bash I can provide instructions to try it. Kinda sad. LC's chunk expressions make our beloved language a nearly ideal fit for so many server tasks. General performance is more or less on par with Python and Ruby where CGI stuff has been a famously good fit- LC can do anything they can do, and with more readable code that's more enjoyable to write. But we need to tighten it up and bring down the resource consumption before I'll stake my reputation evangelizing it beyond the current community of LC diehards. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
Ralph DiMola wrote: > 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 Thanks, Ralph. I do use persistent session data, but in this app I use a custom store, not LC Server's session handling. That's an interesting report, though, and I've added myself to the CC there. This loading-fonts-unnecessarily issue seems to be more related to my circumstance: https://quality.livecode.com/show_bug.cgi?id=14115 I'll know more if I get a chance I put the funky-font-fix workaround in place, but TBH I'm more likely to just move the app to a VPS instead. So it'll be a question of making the time for a funky setup test, and while that might narrow down root causes it won't fix anything since it's unlikely to be addressed anytime soon: two community members who've looked at the engine code believe IF-DEFing the font init would be prohibitively cumbersome given the imported subsystems that would need it (like Skia), and the core team has other priorities. > 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. How certain are you the issue you're seeing is specific to sessions? I've skimmed your report but haven't tested it, so forgive me if this should be obvious, but have you found any other circumstances where file I/0 may be the trigger, rather than session storage specifically? > If you find a solution I'll be interested to see > if it helps me also. If your issue is session-specific, I got nothing. If it may be general resource consumption (mostly memory), the funky-font-fix may do the trick. But setting it up is not for the feint of heart. If you're comfortable with bash I can provide instructions to try it. Kinda sad. LC's chunk expressions make our beloved language a nearly ideal fit for so many server tasks. General performance is more or less on par with Python and Ruby where CGI stuff has been a famously good fit- LC can do anything they can do, and with more readable code that's more enjoyable to write. But we need to tighten it up and bring down the resource consumption before I'll stake my reputation evangelizing it beyond the current community of LC diehards. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: "tsnet (1) Received HTTP/0.9 when not allowed"?
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 rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Thursday, April 01, 2021 1:59 PM To: use-livecode@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 202
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://downloa
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
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 via use-livecode > 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 > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
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 ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: "tsnet (1) Received HTTP/0.9 when not allowed"?
Richard, was there a change in the configuration of your web server recently? Is your web service using php or LC server? 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 Matthias - Matthias Rebbe Life Is Too Short For Boring Code > Am 31.03.2021 um 21:29 schrieb Richard Gaskin via use-livecode > : > > I have an LC app that recently started reporting this error when calling a > web service we wrote: > > tsnet (1) Received HTTP/0.9 when not allowed > > > Searching around the web I see many varied descriptions of how one might > remedy that, but none seem to fit our circumstance. > > Anyone else seen this? What was needed to resolve it? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
"tsnet (1) Received HTTP/0.9 when not allowed"?
I have an LC app that recently started reporting this error when calling a web service we wrote: tsnet (1) Received HTTP/0.9 when not allowed Searching around the web I see many varied descriptions of how one might remedy that, but none seem to fit our circumstance. Anyone else seen this? What was needed to resolve it? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
