MESSAGE
| DATE | 2020-10-04 |
| FROM | Rob De Langhe
|
| SUBJECT | Re: [Hangout - NYLXS] [users@httpd] Re: Alternatives to SSI (server
|
From hangout-bounces-at-nylxs.com Sun Oct 4 19:31:05 2020
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id D40F916403B;
Sun, 4 Oct 2020 19:31:04 -0400 (EDT)
X-Original-To: hangout-at-nylxs.com
Delivered-To: hangout-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 2FBD416401D
for ; Sun, 4 Oct 2020 19:30:27 -0400 (EDT)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 4C4Khx6PwCzhK9
for ; Sun, 4 Oct 2020 19:30:25 -0400 (EDT)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 4C4Khx6MXRz1ZWJ; Sun, 4 Oct 2020 19:30:25 -0400 (EDT)
Resent-From: Ruben Safir
Resent-Date: Sun, 4 Oct 2020 19:30:25 -0400
Resent-Message-ID: <20201004233025.GG16483-at-panix.com>
Resent-To: hangout-at-nylxs.com
X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on
mailcrunch2.panix.com
X-Spam-Level:
X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED,
HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS
autolearn=ham autolearn_force=no version=3.4.3
X-Spam-Relay-Country: US US IN ** IN BE BE BE ** BE
X-Original-To: mrbrklyn-at-panix.com
Delivered-To: mrbrklyn-at-panix.com
Received: from mail2.panix.com (mail2.panix.com [166.84.1.73])
by mailbackend.panix.com (Postfix) with ESMTP id 4C3zDl25F9z1ZDD
for ; Sun, 4 Oct 2020 05:38:15 -0400 (EDT)
Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org
[3.227.148.255])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(No client certificate requested)
by mail2.panix.com (Postfix) with ESMTPS id 4C3zDl1d4LzwrG
for ; Sun, 4 Oct 2020 05:38:15 -0400 (EDT)
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153])
by mxout1-ec2-va.apache.org (ASF Mail Server at
mxout1-ec2-va.apache.org) with SMTP id D670B436DD
for ; Sun, 4 Oct 2020 09:38:12 +0000 (UTC)
Received: (qmail 90604 invoked by uid 500); 4 Oct 2020 09:38:09 -0000
Mailing-List: contact users-help-at-httpd.apache.org; run by ezmlm
Precedence: bulk
Delivered-To: mailing list users-at-httpd.apache.org
Received: (qmail 90594 invoked by uid 99); 4 Oct 2020 09:38:09 -0000
Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org)
(116.203.196.100)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Oct 2020 09:38:09 +0000
Received: from localhost (localhost [127.0.0.1])
by spamproc1-he-de.apache.org (ASF Mail Server at spamproc1-he-de.apache.org)
with ESMTP id 0B0151FF39F
for ; Sun, 4 Oct 2020 09:38:09 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org
Authentication-Results: spamproc1-he-de.apache.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mailprotect.be
Received: from mx1-he-de.apache.org ([116.203.227.195])
by localhost (spamproc1-he-de.apache.org [116.203.196.100]) (amavisd-new,
port 10024) with ESMTP id 5KOJhHMbumVS for ;
Sun, 4 Oct 2020 09:38:08 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=83.217.72.86;
helo=out002.mailprotect.be; envelope-from=rob.de.langhe-at-twistfare.be;
receiver=
Received: from out002.mailprotect.be (out002.mailprotect.be [83.217.72.86])
by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS
id 315267FB7B
for ; Sun, 4 Oct 2020 09:38:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mailprotect.be; s=mail; h=Content-Transfer-Encoding:MIME-Version:
Content-Type:In-Reply-To:References:Subject:To:From:Message-ID:Date:reply-to:
sender:cc:bcc; bh=9i0x69CnrKecOF4PDCrZu1WQhtEiT+1Ex5yiVh6/rWU=; b=X1YbL4X5QE4
dV+3Mnz1F9WOWTrx1RgqpYgLcp7lvh2EtAT18y4Knrgv/iINDDgd0I3DhKfPcEgDFv4dvLglfrtFH
OaEDmt2tUT2bgatxRAiBIJMyOstHRSp6AzeBNNcUdn/vB0a2Ru/0HmYlFVF5cfIfKqLFw9etsJGtk
vSbJCKvKUxrj5FvRz4kqPy2vEl8rrzfRuJgpK2c9FJvv3ZNAVd4xYI4Vo+KCWYkrV24zWhZvsKjry
RagV/cBYhEzQi1TvFg5XeMP8iMSau6BXpH5gVHR2npyR/0UtO07l5sr62t1/JSX1KflPrtUz4AhD+
Ldr1/z+Vckp8g7Aqq2M8VoA==;
Received: from smtp-auth.mailprotect.be ([178.208.39.155])
by com-mpt-out002.mailprotect.be with esmtp (Exim 4.92)
(envelope-from ) id 1kP0Sv-000Dqy-8w
for users-at-httpd.apache.org; Sun, 04 Oct 2020 11:38:01 +0200
Received: from localhost (78-20-141-109.access.telenet.be [78.20.141.109])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by smtp-auth.mailprotect.be (Postfix) with ESMTPSA id 08579C00C1
for ; Sun, 4 Oct 2020 11:38:00 +0200 (CEST)
Received: from s1001.twistfare.int (s1001.twistfare.int [10.50.0.151]) by
www.twistfare.be (Horde Framework) with HTTPS; Sun, 04 Oct 2020 11:37:50
+0200
Date: Sun, 04 Oct 2020 11:37:50 +0200
Message-ID: <20201004113750.Horde.th4uHnrPfY9AaCRgMurjiDA-at-www.twistfare.be>
From: Rob De Langhe
To: users-at-httpd.apache.org
References:
In-Reply-To:
User-Agent: Horde Application Framework 5
MIME-Version: 1.0
X-Originating-IP: 178.208.39.155
X-SpamExperts-Domain: mailprotect.be
X-SpamExperts-Username: 178.208.39.128/27
Authentication-Results: mailprotect.be;
auth=pass smtp.auth=178.208.39.128/27-at-mailprotect.be
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.30)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVV0+GV+GDteI7
BKkmZxrovETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDa+Lo6tyzr6MI4d7c330ant5C
AH6J38ypTMGqmerzumjBrLXJpgmHFOJ7JI08uam7BMmyNbDn7R5kilAhwr3KtPRgtEKbbJiCf5yI
2Oixqpv29K3Gp8HBKlhPMU/wySsmNqiYT7HDpqYNtaBClhqMnWRbN4cS9m3JKQpYnU+jEOY1QXt8
9rIC/Ty04AqNz6UpUOUPX0VHiKUyAtskn6r56iD3bWZ2N6r3HdrvQtOERNbwVc2hlk9uPUCwBk0x
a3S1XK9fBWQRDwtv3Nel3e7AvX+HI6pKLVkzXdxy1hVs/GqOP+82OLATFDSWAs0aHCLjFR4Vg+x7
m0QTiLvJh2scpga+FEE+TmTK/6Hl36Y/23+8Ksk+aedMfNWSnJswrtlNYMcdEaOu89tgCtCwrHQs
NnPw17RyTo/iK8p1aZEnH6AVTveBsm6AaA6YWj1Sfcf7cI5+17rf5V2oLKHXeaqjg0xYsHKVOH8s
++Y8aVPfETxoh9VoIekQHpwUfpYnEThm/0WPcVW4CvuxsCScGMw1twNDOxDy2fugSo5wZVIAvaUm
8kywl1THTVm6sZzsq5pzDNoaitIRC1eXpb64fJQE6RIsyi7QdQWlz6s/31BvFxx7lwgtQOQrpJMt
FhaN/CV092PNDpgLsd6Ddd/s7VM53ngUac2v+OsjE/2z3m/d+cX78NLFpLHRsJIfsA4Jstw5hOaT
ObtjgBNMVzcKYG+LxKTaGmUOGUrMZdwYUeM/xSg8CVsONrMJuGzuoGnKTKcyl+cFaaEnjAB40jE4
BGk0cmn4izD4Fydwhkvq021PYDJ/7yxxPhme/3MrwvZE7vEHUGszJ+li7JqcBmkxeyx+tZADFrPx
3wuOHFmU70rsceZu4BgO6qGz4mDj/WHHKR0wNXf0xLkfge9mzM1qtvMzGiJTUK9I6aaI63iwL61r
DSg+3GW1EDvlbeOCS7QY4RhQvi24yjjzZaSBM/q8/imElA==
X-Report-Abuse-To: spam-at-com-mpt-mgt001.mailprotect.be
Subject: Re: [Hangout - NYLXS] [users-at-httpd] Re: Alternatives to SSI (server
side includes)?
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.30rc1
List-Id: NYLXS Tech Talk and Politics
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Reply-To: users-at-httpd.apache.org
Content-Type: multipart/mixed; boundary="===============0634232093=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"
--===============0634232093==
Content-Type: multipart/alternative; boundary="=_u58nf79HrsVi_87pZabB601"
Content-Transfer-Encoding: 8bit
--=_u58nf79HrsVi_87pZabB601
Content-Type: text/plain; charset=iso-8859-1; format=flowed; DelSp=Yes
Content-Description: Plaintext Message
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
hi Tom,
I simply use (or dynamically construct) a page with iframes, in which
each iframe gets loaded by a separate CGI results;
this is the async way. You can trigger the loading of certain iframes
when user clicks on some button in the main part of the page, then a
Javascript function is called by that button to re-load the contents
of some iframe by a corresponding CGI.
No AJAX needed, but plain HTML + Javascript.
cheers
Rob
Quoting "Scott A. Wozny" :
> Sounds like a job for AJAX, but before throwing out the baby with
> the bath water I'd seriously consider turning up logging with
> timestamps on your existing CGI and seeing if SSI is a loser in its
> entirety or if it's one specific part of the process that is tanking
> your page load times that you can easily fix (you don't say much
> about that data store, but if you've crossed a tipping in regards to
> size or number of records, you may need to reconsider your data
> storage strategy).
> ?
> Also, if you've got really old / dumb clients AJAX might not be a
> great answer whereas SSI is always entirely under your control.
> ?
> Best of luck,
> ?
> Scott
> ?
>
> -------------------------
> FROM: Tom Browder
> SENT: October 3, 2020 2:08 PM
> TO: users-at-httpd.apache.org
> SUBJECT: [users-at-httpd] Re: Alternatives to SSI (server side
> includes)? ?
>
> On Sat, Oct 3, 2020 at 12:18 Tom Browder
> wrote:
>> I have been using server side includes since I started my websites on Apache
> ...
>> Any suggestions for SSI replacement with a more asynchronous method?
>
> Let me be more specific about the data flow I'm using with the landing
> (home) page of my websites:
>
> + the first SSI line executes a CGI program that extracts the CGI and
> SSL variables and their values. Data of interest include: requesting
> IP, email address in the SSL client certificate, time of page load
>
> + the second line executes a CGI program that generates a link to a
> page that presents the current and past statistics of the visitor
> based on the stats in the db updated with the first CGI program
>
> -Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe-at-httpd.apache.org
> For additional commands, e-mail: users-help-at-httpd.apache.org
> ?
--=_u58nf79HrsVi_87pZabB601
Content-Type: text/html; charset=iso-8859-1
Content-Description: HTML Message
Content-Disposition: inline
"http://www.w3.org/TR/REC-html40/loose.dtd">
hi Tom,
I simply use (or dynamically construct) a page with iframes, in which each iframe gets loaded by a separate CGI results;
this is the async way. You can trigger the loading of certain iframes when user clicks on some button in the main part of the page, then a Javascript function is called by that button to re-load the contents of some iframe by a corresponding CGI.
No AJAX needed, but plain HTML + Javascript.
cheers
Rob
Quoting "Scott A. Wozny" <sawozny-at-hotmail.com>:
Sounds like a job for AJAX, but before throwing out the baby with the bath water I'd seriously consider turning up logging with timestamps on your existing CGI and seeing if SSI is a loser in its entirety or if it's one specific part of the process that is tanking your page load times that you can easily fix (you don't say much about that data store, but if you've crossed a tipping in regards to size or number of records, you may need to reconsider your data storage strategy).
Also, if you've got really old / dumb clients AJAX might not be a great answer whereas SSI is always entirely under your control.
Best of luck,
Scott
From: Tom Browder <tom.browder-at-gmail.com>
Sent: October 3, 2020 2:08 PM
To: users-at-httpd.apache.org <users-at-httpd.apache.org>
Subject: [users-at-httpd] Re: Alternatives to SSI (server side includes)? On Sat, Oct 3, 2020 at 12:18 Tom Browder <tom.browder-at-gmail.com> wrote:
> I have been using server side includes since I started my websites on Apache
...
> Any suggestions for SSI replacement with a more asynchronous method?
Let me be more specific about the data flow I'm using with the landing
(home) page of my websites:
+ the first SSI line executes a CGI program that extracts the CGI and
SSL variables and their values. Data of interest include: requesting
IP, email address in the SSL client certificate, time of page load
+ the second line executes a CGI program that generates a link to a
page that presents the current and past statistics of the visitor
based on the stats in the db updated with the first CGI program
-Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe-at-httpd.apache.org
For additional commands, e-mail: users-help-at-httpd.apache.org
--=_u58nf79HrsVi_87pZabB601--
--===============0634232093==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
--===============0634232093==--
--===============0634232093==
Content-Type: multipart/alternative; boundary="=_u58nf79HrsVi_87pZabB601"
Content-Transfer-Encoding: 8bit
--=_u58nf79HrsVi_87pZabB601
Content-Type: text/plain; charset=iso-8859-1; format=flowed; DelSp=Yes
Content-Description: Plaintext Message
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
hi Tom,
I simply use (or dynamically construct) a page with iframes, in which
each iframe gets loaded by a separate CGI results;
this is the async way. You can trigger the loading of certain iframes
when user clicks on some button in the main part of the page, then a
Javascript function is called by that button to re-load the contents
of some iframe by a corresponding CGI.
No AJAX needed, but plain HTML + Javascript.
cheers
Rob
Quoting "Scott A. Wozny" :
> Sounds like a job for AJAX, but before throwing out the baby with
> the bath water I'd seriously consider turning up logging with
> timestamps on your existing CGI and seeing if SSI is a loser in its
> entirety or if it's one specific part of the process that is tanking
> your page load times that you can easily fix (you don't say much
> about that data store, but if you've crossed a tipping in regards to
> size or number of records, you may need to reconsider your data
> storage strategy).
> ?
> Also, if you've got really old / dumb clients AJAX might not be a
> great answer whereas SSI is always entirely under your control.
> ?
> Best of luck,
> ?
> Scott
> ?
>
> -------------------------
> FROM: Tom Browder
> SENT: October 3, 2020 2:08 PM
> TO: users-at-httpd.apache.org
> SUBJECT: [users-at-httpd] Re: Alternatives to SSI (server side
> includes)? ?
>
> On Sat, Oct 3, 2020 at 12:18 Tom Browder
> wrote:
>> I have been using server side includes since I started my websites on Apache
> ...
>> Any suggestions for SSI replacement with a more asynchronous method?
>
> Let me be more specific about the data flow I'm using with the landing
> (home) page of my websites:
>
> + the first SSI line executes a CGI program that extracts the CGI and
> SSL variables and their values. Data of interest include: requesting
> IP, email address in the SSL client certificate, time of page load
>
> + the second line executes a CGI program that generates a link to a
> page that presents the current and past statistics of the visitor
> based on the stats in the db updated with the first CGI program
>
> -Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe-at-httpd.apache.org
> For additional commands, e-mail: users-help-at-httpd.apache.org
> ?
--=_u58nf79HrsVi_87pZabB601
Content-Type: text/html; charset=iso-8859-1
Content-Description: HTML Message
Content-Disposition: inline
"http://www.w3.org/TR/REC-html40/loose.dtd">
hi Tom,
I simply use (or dynamically construct) a page with iframes, in which each iframe gets loaded by a separate CGI results;
this is the async way. You can trigger the loading of certain iframes when user clicks on some button in the main part of the page, then a Javascript function is called by that button to re-load the contents of some iframe by a corresponding CGI.
No AJAX needed, but plain HTML + Javascript.
cheers
Rob
Quoting "Scott A. Wozny" <sawozny-at-hotmail.com>:
Sounds like a job for AJAX, but before throwing out the baby with the bath water I'd seriously consider turning up logging with timestamps on your existing CGI and seeing if SSI is a loser in its entirety or if it's one specific part of the process that is tanking your page load times that you can easily fix (you don't say much about that data store, but if you've crossed a tipping in regards to size or number of records, you may need to reconsider your data storage strategy).
Also, if you've got really old / dumb clients AJAX might not be a great answer whereas SSI is always entirely under your control.
Best of luck,
Scott
From: Tom Browder <tom.browder-at-gmail.com>
Sent: October 3, 2020 2:08 PM
To: users-at-httpd.apache.org <users-at-httpd.apache.org>
Subject: [users-at-httpd] Re: Alternatives to SSI (server side includes)? On Sat, Oct 3, 2020 at 12:18 Tom Browder <tom.browder-at-gmail.com> wrote:
> I have been using server side includes since I started my websites on Apache
...
> Any suggestions for SSI replacement with a more asynchronous method?
Let me be more specific about the data flow I'm using with the landing
(home) page of my websites:
+ the first SSI line executes a CGI program that extracts the CGI and
SSL variables and their values. Data of interest include: requesting
IP, email address in the SSL client certificate, time of page load
+ the second line executes a CGI program that generates a link to a
page that presents the current and past statistics of the visitor
based on the stats in the db updated with the first CGI program
-Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe-at-httpd.apache.org
For additional commands, e-mail: users-help-at-httpd.apache.org
--=_u58nf79HrsVi_87pZabB601--
--===============0634232093==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
--===============0634232093==--
|
|
