Setcookies problem....problem with headers(possibly)

I am trying to use setcookie but I cannot…as I see it the cookie is sent before any headers…nonetheless it still does not work…let me explain:
I have a script that accepts ajax requests for login credentials along with the choise for “remember me”.
If the user has ticked remember me…this code runs.

     $res=setcookie_pers($conn,$_POST['email']);// persistent...cookie is set here...setcookie() is     used...and token is entered in the database.

When this script ends it sends back to the browser a value which indicates which type of user is logging in(a regular user or a business user)…depending on that redirection will take place in different pages.

              window.location.href = "../Administratorcalendar.php";//business user
          else if(data==='regular_user')
          { window.location.href = "appointments.php";}//regular user

If redirection takes place in calendar.php **setcookie does not work**...if for example I edit the code like this

  else if(data==="buz_user")
             // window.location.href = "../Administratorcalendar.php";

setcookie will work and I cannot understand why…setcookie() is called before redirection takes place…so normally there must no be an issue with headers/output sent first

I want to note also that the script were setcookie() is called is in a different directory from calendar.php…if this plays any role at all.

so… setcookie_pers is not a defined PHP function.
I’d need to see what you’re doing inside that function to evaluate why your setcookie is failing.

If you can’t find any of the normal reason why a “headers already sent” error is happening in your code, check the file encoding. Make sure it’s not a standard UTF-8 file. PHP isn’t technically able to handle UTF-8 file encoding.

Some editors/systems, that aren’t specifically meant for PHP development, will save files in a standard UTF-8 format, which includes some meta-data (BOM) at the front of the file. It’ll be invisible in the editor and (most likely) in the browser too, but will still count as part of the HTTP body when parsed by PHP, thus closing off the headers.

Some editors will have a UTF-8 “without BOM” or “in ASCII mode”, allowing UTF-8 encoding for PHP without this downside. (Notepad++ comes to mind.)

It was not a “headers already sent” problem after all…

All my files are of this type:

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Does the above line indicate a standard UTF-8 file or not?

it’s a setting meant for the browser to initialize its HTML parser. but it’s most likely overridden if there is a charset mentioned in the Content-Type HTTP header.

but as such it may or may not equal the real charset.

It doesn’t really tell you either way. What I am talking about isn’t set with any line in the file, it’s how the file is created by your text editor.

If you want to find out, install an editor that can detect the difference (like Notepad++), and open the file in that editor. The editor will tell you what kind of file it is.

In the case of Notepad++, in the lower right corner it’ll indicate the charset. If it has only “UTF-8”, then that’s a problem. But if it says either “ANSI” or “UTF-8 w/o BOM” then you’re good.

Any HTML tags having that value are best replaced by an actual http header with the value if a server side language is being used to generate the page. Those tags attempt to provide an equivalent to the real header when you can’t add it server side and are not always successful in being applied.

I agree there should definitely be an actual HTTP header provided by the server, but I wouldn’t advice replacing it entirely. The Content-Type/Charset meta tag should still be specified in the HTML, if only as a fall-back. Serious issues can come up if neither the server nor the HTML provides a specific charset.
(And you never know if/when the new guy will accidentally screw up the server config.)

HTML5 even has a short-cut meta tag for this purpose:

<meta charset="UTF-8">

what do I have to do to make the server specify the charset.

I though that the meta tag was all there is to it.

No, like @felgall says, the HTTP-EQUIV meta tag was meant to provide an equivalent to a HTTP header when that header was not actually sent. That way the browser has something to fall back on when the HTTP response doesn’t provide it with a real header.

Normally the HTTP server will send the content type automatically, based on the file type. When server-side languages like PHP are involved, they can also be used to specify the content type and charset.

In PHP, specifically, you can set these values in the main config file, using these directives:

default_mimetype = "text/html"
default_charset = "UTF-8"

Note that prior to PHP 5.6, the default_charset was empty/not set by default, so if you are using an earlier version, you should change that and set it. (UTF-8 is a safe choice for most situations.)

You can also change this in the PHP code, if necessary, by simply using the header() function to specify the header:

header("Content-Type: text/html; charset=UTF-8");

Although this is generally redundant for HTML output. It’s more useful when you’re generating other types of output, like JSON or XML.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.