[users@httpd] The .htaccess ANSI (ASCII) Format and linked problems

[Bernard TREMBLAY <po...@trebly.net>]

Hi,

As we can pay attention .htaccess must be only redacted in ANSI.

This rule is not absolute :

    * The Windows version supports the 3 chars which marks the encoding
      of the file.

If on Linux a file coming from windows env with is the 3 format coding
identification is submitted we get :

INTERNAL SERVER ERROR

I just lost 9 days locked because nobody had the idea to check the file
in hexa and had never taking care of the encoding.

Practically if the content is ANSI if will be identical if coded 8859-2
or UTF8 or ANSI and seen identical on editors screens.

Most of editors recognize the format and save into the same is not
changed by user.

If accidentally somebody have to save a full project, it can (this is
what happens) save in UTF-8 the htaccess file.
On development platform which was windows everything was ok.
When the file have been loading by ftp to the server on linux the error
occurred.

So My question and proposal is :

Why all the version will not test for .htaccess if the first 3 chars are
not encoding marks and then either threat the following as ASCII (the
same as on windows) or send a clear message :

"ERROR HTACCESS file must be encoded ANSI"

This probably will earn time and money to people who have to work with
the two platforms and as me have no incident during last seven years...

Best regards

Trebly

Re: [users@httpd] The .htaccess ANSI (ASCII) Format and linked problems

["Postmaster trebly.net" <po...@trebly.net>]

Hi,

Here are my answers and explanations about the particular situation and
difficulties.

Le 31/03/2011 03:40, Nick Kew a écrit :
> On 30 Mar 2011, at 18:21, Bernard TREMBLAY wrote:
>
>> Hi,
>>
>> As we can pay attention .htaccess must be only redacted in ANSI.
> ANSI isn't an encoding.  Unless perhaps you're back in the 1980s
> when the notion of an encoding was undefined.
Sorry but in some editors ANSI is used for ASCII (extended, not native
7bits, it's almost a slip).
>> This rule is not absolute :
>> 	• The Windows version supports the 3 chars which marks the encoding of the file.
> You mean you used an XML editor (or text editor whose developers can't
> tell the difference) and created a file with a BOM?
Not really and what was produced can not be well checked and there was a
default of encoding. So If you don't take care, here the htaccess has
been saved in UTF8 with BOM. This don't changes the content but add the
3 chars of identification.  And I had no mean to check it till know.
This exactly cannot anymore happen to me but I think to the others.
>> If on Linux a file coming from windows env with is the 3 format coding identification is submitted we get :
>>
>> INTERNAL SERVER ERROR
> So you look in your error log!
The problem comes from the applications that are installed for clients
on share-Hosting in this case the user can't get anything of the error
log, he (I) must "imagine".

Often developers ignore that some people on operational applications
don't have access to log files when a crash occurs.

So this is a larger problem : how if the user which can't access the log
file can get the error messages, it is a little paradoxical (because of
the purpose of the log files).

So I keep a soft and db replication but these replication on development
platform it is on windows.

If the incident (wrong data) generates a problem on linux and not on
windows, or comes from differences of installation and or modules
between windows and linux, the problem become immediately difficult to
solve.

For this I have developed the core of a parameter and schema tester soft
to know which is the detailed hosting configuration and enable, disable
or change parameter dynamically by soft at starting the session.

For example we had many difficulties with UTF8 and whole
internationalization because of the hosting was in 8859-2;

In another way as there is no xdebug option in hosting, when something
is wrong we must try a local replication of the incident.

This is a bad situation but I can't change anything and just try to get
tools to manage it in a better way. The whole core of php function and
mysql for parameters and all schema had provided a great help. 

This last problem which could occur at any moment during the last five
years, have stopped the site during 9 days before I could take time and
I finally find the problem. Install a new sub-domain with just a simple
HTML file and a quite empty htaccess and the idea to edit in hexa...
>> So My question and proposal is : 
>>
>> Why all the version will not test for .htaccess if the first 3 chars are not encoding marks and then either threat the following as ASCII (the same as on windows) or send a clear message :
>>
>> "ERROR HTACCESS file must be encoded ANSI" 
> That would be incorrect.
>
> What message did you see in your error log, and what was not clear about it?
> As far as httpd is concerned, a BOM in a htaccess is just garbage.
>
The BOM of the htaccess file was generating "INTERNAL SERVER ERROR" and just the server and level name.
The Hosting service don't gave anyway and we find ourself trying to reproduce the incident, this cost 9 days.

The idea is simply that if an encoding error occurs in htaccess 
The message was simply "ERROR HTACCESS file must be encoded ASCII or syntax error" (the htaccess had before test on one line near 150 lines) and after there is 1,000,000 lines of code...
So to solve we try which very simple file to reproduce the incident. We found after 9 days.

Best regards

Trebly (Bernard TREMBLAY fr)



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] The .htaccess ANSI (ASCII) Format and linked problems

[Nick Kew <ni...@webthing.com>]

On 30 Mar 2011, at 18:21, Bernard TREMBLAY wrote:

> Hi,
> 
> As we can pay attention .htaccess must be only redacted in ANSI.

ANSI isn't an encoding.  Unless perhaps you're back in the 1980s
when the notion of an encoding was undefined.

> This rule is not absolute :
> 	• The Windows version supports the 3 chars which marks the encoding of the file.

You mean you used an XML editor (or text editor whose developers can't
tell the difference) and created a file with a BOM?

> If on Linux a file coming from windows env with is the 3 format coding identification is submitted we get :
> 
> INTERNAL SERVER ERROR

So you look in your error log!

> So My question and proposal is : 
> 
> Why all the version will not test for .htaccess if the first 3 chars are not encoding marks and then either threat the following as ASCII (the same as on windows) or send a clear message :
> 
> "ERROR HTACCESS file must be encoded ANSI" 

That would be incorrect.

What message did you see in your error log, and what was not clear about it?
As far as httpd is concerned, a BOM in a htaccess is just garbage.

-- 
Nick Kew

Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org