dalecosp

I don't see why; if you want to display an accurate *local* time for the user, though, you need to know the user's timezone ... so that would be part of the registration process, or you would at least ask them about their TZ and set a COOKIE or SESSION variable to help you compute local time.

There are plenty of date and time functions.

Does $_SERVER['REDIRECT_REMOTE_USER'] get populated?

Thanks for the well wishes. I'm not attempting to imply this; I'm flat out stating it as the truth, as you can read here.

/me whispers something about BSD and leaves ;-)

5 rows of each subcategory?

Check and see if your SESSION cookie is actually being set. Not sure, but seems like a possibility would be that the browser doesn't have the right cookie to send because the authentication happened in another window. A "modal window" would be preferable in these "Web two point oh" days, anyway. If that helps at all ;-)

Sorry, I spoke too soon. This is wrong, by all standards: echo $the_results;setcookie('tntcon',''); And this would cause exactly the error you've made reference to.

In post #15, you have two curl_execs. So the code now is exactly the same as in post #15, with the exception of having the first curl_exec() call removed? If that's true, I see no problem with the code itself, as far as I can tell. What editor are you using? Does it save with a Byte Order Mark, by any chance?

The "blah blah blah()" is pretty important, as it should be telling you which line the failing call is on. I'm still not convinced it's not the setcookie() --- but you've not shown the code lately...

Of course, that won't work, either, since the headers aren't text/html content-type. An echo in a application/octet-stream would like not be a Good Thing. Seems the best course of action would be "rethink the system". If the user has clicked on a link to download something, he/she should already be aware that a download is going to occur ... seems like you don't really need to re-iterate the point to me...

You can't send output to the browser before a header() call.

Why are you calling curl_exec() twice? You only should need the 2nd one, with the output assigned to $the_results. Most likely, the first curl_exec() is returning output, as instructed, and that's causing the setcookie() to fail.

One more thing to remember: the "output" script must send a valid MIME type. Here's a snippet from something in use here: $file=$path."somename.pdf";header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the pastheader("Content-type: application/pdf");readfile($file); Since you appear to be reading file info from your database, your database should probably also contain a MIME type (or marker for MIME type) unless the files are all the same type (text, pdf, whatever)... [edit]I see Barand has just now addressed this in his example.[/edit]

Try the system error logs as well. Not sure if anything would be there, but we're talking about a serious error (as far as the system is concerned). As for installing bug fixes for PHP, the usual answer is to simply (heh, "simply?") upgrade to the newer/newest version of PHP. You mention /var/www and /usr/lib ... I'm guessing some Linux?

I mean: //note there are TWO semicolons below; one is for SQL... $sql = "insert into mysql_conventions (id,name,description) values ('','Semicolons','SQL statements should end with a semicolon.'); "; $query = mysqli_query($some_server,$sql); At this point, we're kind of grasping at straws. You might double-check Barand's question; perhaps the page IS being submitted more than once...

Weird bug, then. Try converting your insert to not use curly braces, maybe? There aren't any semicolons in the input, are there? I guess you might try adding one in the *right* place.

Well, do you think you have it fixed, then? I always call the auto_increment field in my inserts, using '' as I showed. As for moving to mysqli_ --- I didn't find it too hard. Basics: 1. Mysqli_ requires the connection passed to it for most calls: mysqli_query($connection,$sql); I believe the reason is to allow for multiple connections to different hosts. 2. Some of the "functions" are gone because Mysqli already takes care of them. I still find myself typing "$result->num_rows();" --- but I don't need to; Mysqli has already returned that number, and it's now a variable (and NOT a function): 'echo $result->num_rows." were returned.";' 3. There is no mysqli_result function (IMO, this kind of bites --- I used it often for grabbing one result from a query). I found someone had written one, and I use it when I can find no better option.

You need to read the server and system logs at this point. Also, what version of PHP, and what date? There some fairly recent bug fixes for OPcache...

Having read your edits, I think we need to know your table structure. Also, please note that mysql_* is deprecated LONG ago, and your code is in danger of becoming hopelessly antiquated in less than 5 years. You might take a look at mysqli_* functions....

Would this help debug? <? session_start(); include("connect.php"); $_SESSION['Email'] = mysql_real_escape_string($_POST["Email"]); $_SESSION['Name'] = mysql_real_escape_string($_POST["Name"]); $_SESSION['Telephone'] = mysql_real_escape_string($_POST["Telephone"]); //note we'll be telling it to set the ID ... change "ID" as necessary for your database. Using the null string will suffice. $query = "INSERT INTO User (ID,Name, Telephone, Email, FirstReg, LastLogin) VALUES ('','{$_SESSION['Name']}','{$_SESSION['Telephone']}','{$_SESSION['Email']}',NOW(),NOW())"; $result = mysql_query($query); if (!$result) { //your error code } else { echo "Insert successful. Last insert id: ".mysql_insert_id(); } ?>

SPF is a protocol: "Sender Protection Framework", if I remember right off the top of my head. The "lists" I refer to are the email lists at openspf.org, where some helpful sysadmins and others hang and answer questions about implementation of the protocol. Also "IIRR" (if I remember right - or IIRC [correctly!]) ... the SPF protocol basically consists of adding an additional DNS record to your domain's zonefiles, after which the MTA's on the 'Net will "do the right thing" and trust that mail coming from that server is actually being sent by your domain, which *should* help with deliverability.

Well, it's pretty darn late here. If it is where you are, I'd give it a rest. Fresh eyes, fresh brain tomorrow might help a bit. :-)

If you want the form/data to be posted to the URL ($urlcode), you have to call curl_exec.

Write this script and run it, (CLI, or Browser): phpinfo(); That should tell you quite a bit. The INI file, in particular, will be noted.