We use the trick of replacing the ampersands and question marks in a URL
with slashes in order to have our website indexed by search engines.
Instead of having the URL appear as:
MySite.cfm?VarName=Value
it appears as
MyPage.cfm/VarName/Value
This works extremely well in CF5 on IIS5 (patched
aRawUrlParam=ListToArray(lRawUrlParam,/)
cfloop from=1 to=#ArrayLen(aRawUrlParam)# index=i step=2
cfif i mod 2 eq 1 and i+1 lte ArrayLen(aRawUrlParam)
cfset url.#aRawUrlParam[i]#=Evaluate(aRawUrlParam[i+1])/cfif
/cfloop
- Original Message -
From: MW [EMAIL PROTECTED]
To: CF-Talk [EMAIL
The approach that I would take is to remove CF from the picture. Do a
simple html form posting to an html page and see if you get the same
'RePost' results for apache and IIS. If so, MX is not the culprit. You
might also check to see if CF influences the headers while you perform
this test by
I can give you the definitive answer on this after much research. It is
caused by the following:
1) The user submits a form as a 'post'
2) The browser displays the results of the post
3) The user goes to another page
4) The user hits the back button to return to the results page from the
post
5)
I am no master of the http protocol. It is very interesting that you
have isolated everything down to the CF 5 and CF MX servers. How
different is the actual html file -- just a little whitespace? I expect
that this can't be the cause.
It has to be some difference in the http communication
Server.log entries, such as the following, have nothing to do with
the
client, correct?
Warning,4324,07/08/02,10:24:17,,Template:
D:\websites\intranet\sign-in\index.cfm, Ran: 10 seconds.
Correct. This means CF took 10 seconds to run that template (yuk).
By placing URL vars in a
We had a terrible time with CFFile and uploads. We got not only the
memory spike, but an unbelievable spiking of CPU's to 100% for the full
duration of the transfer, in our development and production
environments, and in test code to isolate the problem. The side effect
was that it slowed
The COM problem is why we put off our plans to migrate to MX. Otherwise,
we would have purchased the upgrades and begun the process of testing
for our next milestone.
Matt
--
cto
Turbo Squid
-Original Message-
From: Frank Mamone [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002
The COM problem is why we put off our plans to migrate to MX. Otherwise,
we would have purchased the upgrades and begun the process of testing
for our next milestone. We'll pick up the issue when MX is patched...
Matt
--
cto
Turbo Squid
-Original Message-
From: Mark A. Kruger - CFG
It turns out that the CF server replaces the CF code with HTML and
returns the output page. It has no default logic to suppress whitespace
-- who knows, maybe you are trying to output well formatted html code.
It literally just replaces out the cfml that it parses with whatever the
cfml was
Apparently, CF doesn't support unicode. How are people dealing with Ü
(umlauts) and other characters like å?
I've gotten complaints from some Swedes since their address is garbeled...
TIA,
Matt
BTW, if you reply, please cc me, too. I've had some wacky behavior with the
listserv recently.
This is a multi-part message in MIME format.
--=_NextPart_000_0002_01BFFC6E.F87236A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Here's the URL2Form tag that I mentioned. I placed a call to it in the
Application.cfm for load testing purposes with
We found a few that cost major cash -- I think the cheap one Dave mentioned
a while back was $30k. We use Microsoft's tool (W.A.S.), which is okay, but
suited to ASP. I hacked a tag together "URL2Form" tag which copies all URL
vars to the FORM scope since WAS doesn't seem to like posting FORM
13 matches
Mail list logo
