| Author |
 Topic  |
|
fuzzie
Starting Member
35 Posts |
 Posted - 16 August 2000 : 10:20:24
|
I went to your link above, selected all, copied and pasted it in notebook, then ftped it up.
Still get that header error. I have made no mods other than that.
I took out the auto login mod, in notebook again, and there error is gone??
Darn, darn, darn.
|
 |
|
|
Kal Corp
Average Member
USA
878 Posts |
Posted - 16 August 2000 : 16:11:59
|
Just add the update not the hold config.asp <img src=icon_smile_big.gif border=0 align=middle>
There are other Mods in there.
That is why added the
look for
'######## Auto Logon Mod ##########
Find where it is to your config.asp and add it.
Sorry about that |
|
|
|
fuzzie
Starting Member
35 Posts |
Posted - 20 August 2000 : 16:23:43
|
config.asp or register.asp?
I have added to register.asp only where the ################### is located at ... I did it in Notepad, not Frontpage. Still get that header error, I think the meta refresh tag is doing it. If I try to do it in Frontpage, the meta refresh tag moves to the beginning of the file and inserts head and /head tags around it.
Killing me slowly.
Thanks for your patience.
|
|
|
|
Kal Corp
Average Member
USA
878 Posts |
Posted - 20 August 2000 : 21:49:36
|
| Sorry Register.asp |
|
|
|
fuzzie
Starting Member
35 Posts |
Posted - 21 August 2000 : 00:49:52
|
Time for me to throw in the towel on this one. I downloaded the lasted SR3 release, and started from scratch, only mod was the auto login...same old header error. (I inserted the mod in notepad to avoid the Frontpage problem).
Dead, floating on the water, waiting to reach the falls.
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 21 August 2000 : 01:23:47
|
fuzzie,
you could try something drastic like insering a response.buffer=true in config.asp. That should solve any header problem you might be having....
I'll have a look at it for V3.1 anyhow. Seems like a nice mod (and ofcourse the admin will be able to switch it on/of in V3.1 <img src=icon_smile_wink.gif border=0 align=middle>)
<center><b>Pierre Gorissen </b>
<font color=purple><font size=1>I'm a fulltime workaholic back from vacation...</font id=size1></font id=purple></center> |
|
|
|
fuzzie
Starting Member
35 Posts |
Posted - 21 August 2000 : 01:35:33
|
Drastic! Why is this drastic?
But who really cares, because I added it as you suggested and IT WORKS!!!!
Thanks a ton.
Will this do anything else to board that you know of?
|
|
|
|
slemieux
Junior Member
USA
234 Posts |
Posted - 21 August 2000 : 05:24:30
|
Nothing more than slowing your board down a little. But very little, you may not even notice a change.
Scott LeMieux |
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 21 August 2000 : 05:32:41
|
Ehm, as far as I know it rather speeds it up <img src=icon_smile_question.gif border=0 align=middle>
<center><b>Pierre Gorissen </b>
<font color=purple><font size=1>I'm a fulltime workaholic back from vacation...</font id=size1></font id=purple></center> |
|
|
|
Kal Corp
Average Member
USA
878 Posts |
Posted - 21 August 2000 : 21:43:13
|
Insering a response.buffer=true in config.asp
Hay gor, Did i do something wrong? <img src=icon_smile_shock.gif border=0 align=middle>
Whats up with this? Thanks for the Help |
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 22 August 2000 : 04:04:47
|
Kal Corp,
Cookies have to be written in the header of a HTML-document.
The <b>register.asp</b> includes <b>inc_top.asp</b> which starts writing/outputting the HMTL-document to the browser. Because the headers is allready send to the browser, you get an error when you want to add cookie-values to it afterward.
What Response.buffer = true does is <i>buffer</i> the document until the document is completely build or the Response.flush (sends the part of the document that has been build so far) or the Response.clear (remove everything is the buffer).
Buffering can be enabled in the asp-page and at the server !
If you are using IIS 5.0 (W2K) then Response.Buffer is true by default, wich means you wouldn't get an error either way.
See Microsoft asptips at MSDN for this info:
<i>
<b>Tip 14: Use Response Buffering</b>
You can buffer a whole page worth of output by turning on “response buffering.” This minimizes the amount of writes to the browser and thus improves overall performance. Each write has a lot of overhead (both in IIS and in the amount of data sent down the wire), so the fewer the writes there are, the better. TCP/IP works much more efficiently when it can send a few large blocks of data than when it has to send many small blocks because of its slow start and Nagling algorithms (used to minimize network congestion).
There are two ways of turning response buffering on. First, you can turn on response buffering for an entire application, using the Internet Services Manager. This is the recommended approach and response buffering is turned on by default for new ASP applications in IIS 4.0 and IIS 5.0. Second, on a page-by-page basis, you can enable response buffering by placing the following line of code near the top of the ASP page:
<% Response.Buffer = True %>
This line of code must be executed before any response data has been written to the browser (that is, before any HTML appears in the ASP script and before any Cookies have been set using the Response.Cookies collection). In general, it is best to turn response buffering on for an entire Application. This allows you to avoid the above line of code on every page.
<b>Response.Flush</b>
One common complaint about response buffering is that users perceive ASP pages as being less responsive (even though the overall response time is improved) because they have to wait for the entire page to be generated before they start to see anything. For long-running pages, you can turn response buffering off by setting Response.Buffer = False. However, a better strategy is to utilize the Response.Flush method. This method flushes all HTML that has been painted by ASP to the browser. For example, after painting 100 rows of a 1,000-row table, ASP can call Response.Flush to force the painted results to the browser; this allows the user to see the first 100 rows before the remaining rows are ready. This technique can give you the best of both worlds—response buffering combined with the gradual presentation of data to the browser.
(Note that in the above example of a 1,000-row table, many browsers won’t start painting the table until they see the closing </table> tag. Check your targeted browsers for support. To get around this, try breaking the table into multiple tables with less rows, and call Response.Flush after each table. Newer versions of Internet Explorer will paint tables before they are fully downloaded, and will paint especially fast if you specify the table’s column widths; this avoids forcing Internet Explorer to calculate the column widths by measuring the width of the contents of every cell.)
The other common complaint about response buffering is that it can use a lot of server memory when generating very large pages. Leaving aside the wisdom of generating large pages, this problem can also be addressed with judicious use of Response.Flush.
</i>
BTW, I added your code to the live version of V3.1 Beta 1 but modified it a bit:
<pre id=code><font face=courier size=2 id=code>
<%
if strAuthType = "db" then
select case ChkUser2(Request.Form("Name"), Request.Form("Password"))
case 1, 2, 3, 4
Call DoCookies()
strLoginStatus = 1
case else
strLoginStatus = 0
end select
end if
%>
</font id=code></pre id=code>
<center><b>Pierre Gorissen </b>
<font color=purple><font size=1>I'm a fulltime workaholic back from vacation...</font id=size1></font id=purple></center> |
|
|
|
Kal Corp
Average Member
USA
878 Posts |
Posted - 22 August 2000 : 20:32:50
|
That explains why it worked for others, and me.
Thanks |
|
|
|
Kal Corp
Average Member
USA
878 Posts |
Posted - 28 August 2000 : 21:55:58
|
Tested on 3.1 b2. Looks good
Thanks |
|
|
|
Topic |
|
Topic Locked
