On Thu, 2012-08-30 at 00:16 +0200, Christoph Anton Mitterer wrote:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ $1.php [last]
Tried them out in the meantime.
Seem to work as expected.
Cheers,
CHris.
smime.p7s
Description: S/MIME
On 2012-08-28 18:03:02 +0200, Christoph Anton Mitterer wrote:
On Tue, 2012-08-28 at 15:37 +0100, Ian Jackson wrote:
Then if there is a charset parameter, with a value that refers to
some known text character set, I think that one can assume that
the contents are encoded with this
On Wed, Aug 29, 2012 at 2:29 AM, Charles Plessy ple...@debian.org wrote:
Dear Ondřej and everybody,
I would like to keep separate the two following issues.
1) Whether or not to give a private media type to PHP files in Debian, and
if yes, which one.
2) Provide a smooth upgrade to our
On Wed, 2012-08-29 at 09:28 +0200, Ondřej Surý wrote:
With much cooler head and weekend after me and after carefull
consideration of Chris's
comments I have decided to go with:
Good =)
Some comments to your text :)
php5 (5.4.4-7) unstable; urgency=low
* As a side effect of MIME-Type
Chris,
your text is very hard to read and parse.
Could you assemble your comments into consistent paragraphs of
suggested texts? (E.g. the final versions of the text you suggest we
use. Or send a patch.)
O.
On Wed, Aug 29, 2012 at 10:32 AM, Christoph Anton Mitterer
cales...@scientia.net
Hey Ondřej.
On Wed, 2012-08-29 at 11:11 +0200, Ondřej Surý wrote:
your text is very hard to read and parse.
Sorry O:-)
Below you find the texts as I would have written them.
1) Especially the README.Debian text is much more elaborate.
Why? What we try with the whole issue here is to prevent
Christoph Anton Mitterer writes (Re: About the media types text/x-php and
text/x-php-source):
On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
There are a fair number
of email clients out there that, rightly or wrongly, will not display
inline attachments of type application
On 2012-08-28 04:32:18 +0200, Christoph Anton Mitterer wrote:
On Mon, 2012-08-27 at 11:03 +0200, Vincent Lefevre wrote:
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously there's a small border; I guess IETF's idea is:
Can it be exectued/interpreted directly or by
On 2012-08-28 11:43:32 +0100, Ian Jackson wrote:
Christoph Anton Mitterer writes (Re: About the media types text/x-php and
text/x-php-source):
On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
There are a fair number
of email clients out there that, rightly or wrongly
Vincent Lefevre writes (Re: About the media types text/x-php and
text/x-php-source):
On 2012-08-28 11:43:32 +0100, Ian Jackson wrote:
But the clients aren't broken. They simply haven't been taught about
every possible programming language. That is not a bug. There will
always be some
Vincent Lefevre writes (Re: About the media types text/x-php and
text/x-php-source):
On 2012-08-28 04:32:18 +0200, Christoph Anton Mitterer wrote:
On Mon, 2012-08-27 at 11:03 +0200, Vincent Lefevre wrote:
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously
Ian Jackson writes (Re: About the media types text/x-php and
text/x-php-source):
This is the wrong way to think of it. The right way is is it
intended by the sender to be executed by the recipient _as part of
display of the message_ ?
Oh and I should draw the obvious conclusion about PHP
Ian,...
Again, AFAIU, IETF nor the RFCs do consider the MIME types as way to
determine what the sender/creator intends the recipient to do with it.
So any assumptions you made about files attached to emails, etc. do IMHO
simply not fit.
And actually that's the way we already have; the clients
On 2012-08-28 12:36:22 +0100, Ian Jackson wrote:
Vincent Lefevre writes (Re: About the media types text/x-php and
text/x-php-source):
Now, the sender could also provide a charset with
application/*, in which case the recipient client should know
that this is necessarily text
On 2012-08-28 14:49:53 +0200, Christoph Anton Mitterer wrote:
Ian,...
Again, AFAIU, IETF nor the RFCs do consider the MIME types as way to
determine what the sender/creator intends the recipient to do with it.
Perhaps it would be more clear like that: one may want to consider
a script as a
On Tue, 2012-08-28 at 15:20 +0200, Vincent Lefevre wrote:
Perhaps it would be more clear like that: one may want to consider
a script as a program/application that can be executed, in which
case application/* should be used; but one may also want to regard
it as text, in which case text/plain
On 2012-08-28 15:53:51 +0200, Christoph Anton Mitterer wrote:
On Tue, 2012-08-28 at 15:20 +0200, Vincent Lefevre wrote:
Perhaps it would be more clear like that: one may want to consider
a script as a program/application that can be executed, in which
case application/* should be used; but
On Tue, 2012-08-28 at 16:05 +0200, Vincent Lefevre wrote:
It doesn't break anything.
Well one should usually not add any personal interpretations to
standards,... because eventually this will cause troubles.
If the goal is to read the file as text,
then text/plain is fine.
Ah... I guess I
Vincent Lefevre writes (Re: About the media types text/x-php and
text/x-php-source):
Then if there is a charset parameter, with a value that refers to
some known text character set, I think that one can assume that
the contents are encoded with this charset, thus can be displayed
as text.
I
Christoph Anton Mitterer writes (Re: About the media types text/x-php and
text/x-php-source):
On Tue, 2012-08-28 at 16:05 +0200, Vincent Lefevre wrote:
You misread what I've said. text/javascript and text/ecmascript
(which were used for execution -- this is what this RFC is about
On Tue, 2012-08-28 at 15:41 +0100, Ian Jackson wrote:
You misread what I've said. text/javascript and text/ecmascript
(which were used for execution -- this is what this RFC is about)
are obsolete, but not text/plain.
I think this is probably a mistake by the IETF.
Well, I doubt, but
Christoph Anton Mitterer writes (Re: About the media types text/x-php and
text/x-php-source):
I think it already is when you use e.g. application/javascript.
And I think, that MIME types are intended to hint the client of what
kind content is, but not what to do with it.
I think that's
On Tue, 2012-08-28 at 15:37 +0100, Ian Jackson wrote:
Then if there is a charset parameter, with a value that refers to
some known text character set, I think that one can assume that
the contents are encoded with this charset, thus can be displayed
as text.
I don't think that follows at
On 2012-08-28 16:19:29 +0100, Ian Jackson wrote:
*.php files should be recognised as text/x-php or text/x-php-source by
our mime types file.
If Apache (or some other webserver) wants to automatically execute
*.php files (whether the url referring to foo.php is is
http://example.com/foo.php
Dear Ondřej and everybody,
I would like to keep separate the two following issues.
1) Whether or not to give a private media type to PHP files in Debian, and
if yes, which one.
2) Provide a smooth upgrade to our users who use Apache's mod_negociation in a
way
that is different to
On Sun, Aug 26, 2012 at 7:49 PM, Christoph Anton Mitterer
cales...@scientia.net wrote:
I've never seen anyone using that.
Well, we had at least two bugreports for that. So your argument I
have never seen... says nothing.
So honestly, I'd simply drop support for that, and add perhaps a note to
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously there's a small border; I guess IETF's idea is:
Can it be exectued/interpreted directly or by some interpreter? Then
application/*
Or compiled executed, I suppose.
But what if the intent is to display the source
Vincent Lefevre vinc...@vinc17.net writes:
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously there's a small border; I guess IETF's idea is: Can it
be exectued/interpreted directly or by some interpreter? Then
application/*
Or compiled executed, I suppose.
But
Hey Ondřej.
On Mon, 2012-08-27 at 09:15 +0200, Ondřej Surý wrote:
Well, we had at least two bugreports for that. So your argument I
have never seen... says nothing.
Ok,... that point goes to you ;)
So honestly, I'd simply drop support for that, and add perhaps a note to
NEWS.
I don't
On Mon, 2012-08-27 at 11:03 +0200, Vincent Lefevre wrote:
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously there's a small border; I guess IETF's idea is:
Can it be exectued/interpreted directly or by some interpreter? Then
application/*
Or compiled executed,
On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
There are a fair number
of email clients out there that, rightly or wrongly, will not display
inline attachments of type application/*, but will do so for text/*.
Not only MUAs, unfortunately.
This
switch therefore means that attached
Christoph Anton Mitterer cales...@scientia.net writes:
On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
This switch therefore means that attached scripts have to be saved and
opened separately rather than viewed directly inline in the mail
client, which is occasionally quite awkward.
Hey Charles, Ondřej, et all.
On Sat, 2012-08-25 at 10:41 +0900, Charles Plessy wrote:
Le Sat, Aug 25, 2012 at 12:46:33AM +, Christoph Anton Mitterer a
écrit :
Maybe the mime-support maintainer(s) can set these as goals for
jessie :)
Syncing with IANA and cleaning up unofficial
Hey Benjamin
On Sat, 2012-08-25 at 15:44 +0200, Benjamin Drung wrote:
text/x-java
text/x-haskell
[...]
Java and Haskell are compiled, but not interpreted languages.
I guess (!!) what was meant there was the source files, e.g. in case of
Java one has:
*.java - source file
*.class - binary
* The fix for second bug #670945 (e.g. http://localhost/file not
caught by mod_negotiation) was fixed in mime-support 3.52-1.1.
The two bug reporters, the apache maintainer and me are all saying
that this bug should be fixed in apache or PHP, not in
mime-support.
As pointed out
On Sun, 2012-08-26 at 19:55 +0200, Christoph Anton Mitterer wrote:
Hey Benjamin
On Sat, 2012-08-25 at 15:44 +0200, Benjamin Drung wrote:
text/x-java
text/x-haskell
[...]
Java and Haskell are compiled, but not interpreted languages.
I guess (!!) what was meant there was the source
Hi Stefan,
Le Sun, Aug 26, 2012 at 08:18:40PM +0200, Stefan Fritsch a écrit :
* The fix for second bug #670945 (e.g. http://localhost/file not
caught by mod_negotiation) was fixed in mime-support 3.52-1.1.
The two bug reporters, the apache maintainer and me are all saying
that this
I have been coordinating the resolution of the bugs about the PHP media types
with the different players including you and the release team, and we reached
a
consensus. Then you suddenly changed your mind overnight, and went for
another
solution without contacting all the parties.
I did
Le Sat, Aug 25, 2012 at 08:42:38AM +0200, Ondřej Surý a écrit :
* The fix for second bug #670945 (e.g. http://localhost/file not
caught by mod_negotiation) was fixed in mime-support 3.52-1.1.
The two bug reporters, the apache maintainer and me are all saying that this
bug should be fixed in
Am Freitag, den 24.08.2012, 23:28 +0200 schrieb Ondřej Surý:
Chris, this is surely not critical severity. I have cloned your bug
report, assigned it a right severity and retitled it to mime-support:
use of text/ for interpreted languages is discouraged since we have
several interpreted
On Sat, Aug 25, 2012 at 03:44:37PM +0200, Benjamin Drung wrote:
Java and Haskell are compiled, but not interpreted languages.
Haskell is sometimes interpreted.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Dear all,
I note that neither Fedora nor Ubuntu systems associate the text/x-php
and text/x-php-source media types to .php files by default.
Today, a rogue NMU on the mime-support package added these associations in
Debian. I intend to revert that change unless there there is a solid
On 08/24/2012 10:04 PM, Charles Plessy wrote:
Dear all,
I note that neither Fedora nor Ubuntu systems associate the text/x-php
and text/x-php-source media types to .php files by default.
Today, a rogue NMU on the mime-support package added these associations in
Debian. I intend to revert
Hi Charles, et all.
On Fri, 2012-08-24 at 23:04 +0900, Charles Plessy wrote:
I note that neither Fedora nor Ubuntu systems associate the text/x-php
and text/x-php-source media types to .php files by default.
Today, a rogue NMU on the mime-support package added these associations in
Debian.
On Fri, Aug 24, 2012 at 6:36 PM, Thomas Goirand z...@debian.org wrote:
On 08/24/2012 10:04 PM, Charles Plessy wrote:
Dear all,
I note that neither Fedora nor Ubuntu systems associate the text/x-php
and text/x-php-source media types to .php files by default.
Fedora uses IANA as an
Le Fri, Aug 24, 2012 at 11:28:33PM +0200, Ondřej Surý a écrit :
Also I don't think you have a definitive say in what associations are
needed in mime-support package. It's up to individual users of
mime-support package (read individual packages) to define what they
need for correct
On Fri, 2012-08-24 at 23:28 +0200, Ondřej Surý wrote:
Also I don't think you have a definitive say in what associations are
needed in mime-support package. It's up to individual users of
mime-support package (read individual packages) to define what they
need for correct functionality. I think
Le Sat, Aug 25, 2012 at 12:46:33AM +, Christoph Anton Mitterer a écrit :
Maybe the mime-support maintainer(s) can set these as goals for
jessie :)
Syncing with IANA and cleaning up unofficial definitions. :)
Sorry to be in bad mood, but I do not think that I need more reminders to keep
48 matches
Mail list logo
