 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thus, if you cannot view the message it simply implies your newsreader does
> not support this format. Your message header is not too precise which
> version of Mozilla's newsreader you are using. If it is an early version, I
> do recall their newsreader having many bugs and problems in general, so if
> the current Mozilla docs suggest it should support this format, maybe the
> current version does indeed do so.
my browser does not support the format either:
Netscape 7.1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
Netscape/7.1 (ax)
I am a bit surprised by that if it is a common format.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Before anyone takes offense, let me clarify that I do indeed know this
is a private server, maintained and made available to me for free. If
the following sounds harsh, it's nothing personal, it's just a pet peeve
of mine. But hopefully nobody will even think to take anything
personally. The use of the word "you" here doesn't mean you personally,
and terms like "broken" are not to be interpreted pejoratively.
Thorsten Froehlich wrote:
>>*If* the web site is going to send things out as uuencoded, it's quite
>>important not to lie about that and hence not to put
>> content-type: text/plain
>>in the headers, because it's obviously not plain text.
>
> But that is what is inside and the header is correct!
Um, no. What's inside is definitely something like a bitmap, and not
something that could be (say) translated to French. Hence, it's not
"plain text" as such, but rather something encoded to look like plain
text. By adding a content-type, you've specifically instructed
newsreaders to show to the viewer exactly what's in the message, using
the glyphs related to the character set. In other words, by saying
Content-Type: text/plain; charset=iso-8859-1
you're telling the newsreader "this is a chunk of text encoded as
ISO-8859-1, so you should look up each byte of the message, index into
the appropriate font table, and draw the image of that character on the
screen to display it.
You're definitely not saying "look at the text, try to guess whether the
sender is lying about what's really there, try to reverse engineer the
content encoding, then try to guess based on the content what kind of
file it actually is, and if it comes up as a bitmap, decompress the
bitmap and draw individual pixels on the screen in the right colors."
That's definitely not "text". :-)
Were this stored in a database, I would not want to include the body of
this message in full-text searches, for example.
> Headers never apply
> to attachments, thus it is irrelevant what is in the header.
That's the problem. It's not an "attachment." It's a piece of text.
That's what your headers say.
Indeed, in this context, talking about "attachment" is bogus, since MIME
doesn't say anything about "attachments". You have content types and
content transfer encodings. There's no such concept as an "attachment"
in standard internet email.
> Even if not, the robustness principle dictates that newsreaders have to
> display content regardless of the format they assume if the content is
> something they are able to decode. And the newsreaders I have for testing
> do this without problems.
Correct. However, if you say "Hey, this is plain text" and that's what
the newsreader shows, I'd say your newsreader is doing the Right Thing.
Just like if you said "Hey, this is japanese" and your newsreader tried
displaying japanese characters instead of the english you typed, because
it couldn't decode it and guess it's english.
Trying to compensate for people who say "Hey, this is an image" and then
attaching an .exe is where you get many of your viruses.
In other words, "two wrongs don't make a right." Just because you have
many newsreaders that compensate for brokenness doesn't mean it isn't
broken, and the newsreaders that don't compensate for your broken posts
aren't broken either.
That said, I appriciate it's a private server made available to me for
free, so I'm not upset or anything. Just explaining what the problem is. :-)
> Thus, if you cannot view the message it simply implies your newsreader does
> not support this format.
That's incorrect. Had it been encoded as an "attachment", it would work.
Had it been encoded as "I don't know what this is" it would work.
I am using 1.6 mozilla. Since I just upgraded maybe a month ago, I don't
think that's the problem. If you post a uuencoded file inside a
mime-complient header that claims it's not uuencoded, then mozilla does
(and always did, and *should*) show it as plain text, just how the
sender said.
--
Darren New, San Diego CA USA (PST)
I am in geosynchronous orbit, supported by
a quantum photon exchange drive....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Nope, Darren is wrong.
Trust me. See my long rambling rant. "I tested it and it works" doesn't
mean "it's right".
> Still, if many people here use odd newsreaders rather than the mainstream
> ones, there will probably be little choice but to generate full MIME
> messages <sigh>
If you're generating the base-64 already, it's a trivial fix. All you
have to do is put "Content-type: image/whatever" instead of
"text/plain", and get rid of the "begin" line, and you're golden.
--
Darren New, San Diego CA USA (PST)
I am in geosynchronous orbit, supported by
a quantum photon exchange drive....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <407d86f4@news.povray.org> , Darren New <dne### [at] san rrcom> wrote:
> You're definitely not saying "look at the text, try to guess whether the
> sender is lying about what's really there, try to reverse engineer the
> content encoding, then try to guess based on the content what kind of
> file it actually is, and if it comes up as a bitmap, decompress the
> bitmap and draw individual pixels on the screen in the right colors."
> That's definitely not "text". :-)
No, that is exactly what I am saying. It is the way Usenet messages need to
be decoded! Sad, but true.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <c5jtp0$8cc$1@chho.imagico.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> I wonder what newsreaders you tried.
The one I am posting with is one of those I tried with. Works just fine -
well, except that it doesn't support PNG images, so I get a PNG attachment
to view with an external viewer. It displays JPEGs just fine, however.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> [...]
>
> Still, if many people here use odd newsreaders rather than the mainstream
> ones, there will probably be little choice but to generate full MIME
> messages <sigh>
uuencoded would be just fine.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> The one I am posting with is one of those I tried with. Works just fine -
> well, except that it doesn't support PNG images, so I get a PNG attachment
> to view with an external viewer. It displays JPEGs just fine, however.
That's surely one of the most used newsreaders here... ;-)
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <407d86f4@news.povray.org> , Darren New <dne### [at] sanrrcom> wrote:
> Just like if you said "Hey, this is japanese" and your newsreader tried
> displaying japanese characters instead of the english you typed, because
> it couldn't decode it and guess it's english.
Guess what, that is what one really has to do. If you find a header you
don't know, you have little choice but to ignore it.
> Trying to compensate for people who say "Hey, this is an image" and then
> attaching an .exe is where you get many of your viruses.
No, users opening executable attachments from unknown sources on the
internet will eventually have to learn more about Darwinism ;-)
> In other words, "two wrongs don't make a right." Just because you have
> many newsreaders that compensate for brokenness doesn't mean it isn't
> broken, and the newsreaders that don't compensate for your broken posts
> aren't broken either.
There is no standard for Usenet attachments. Remember that MIME standards
for Multipurpose Internet Mail Extensions. It is common these days, yes, as
it uuencoded attachments you match by searching for a magic string ("begin")
followed by what looks like Unix file attributes and a filename thingy.
> I am using 1.6 mozilla. Since I just upgraded maybe a month ago, I don't
> think that's the problem. If you post a uuencoded file inside a
> mime-complient header that claims it's not uuencoded, then mozilla does
> (and always did, and *should*) show it as plain text, just how the
> sender said.
No, you are misunderstanding how decoding Usenet messages has to be done.
The fact that you observe that most messages you find are decoded correctly
is that there are more common formats and their decoding is tested better.
However, this certainly does not say those messages are encoded correctly at
all. If you are looking for correctly encoded Usenet messages with
attachments, you cannot find any because Usenet attachments have never been
fully standardised. This is the main problem when you have to decode them,
and that is why newsreaders have to eat absolutely every junk and still try
to make something meaningful out of it. Believe me, I have had to deal with
message formats more than I would like to - getting the web news view to
decode as many messages as it does the way it does (with finite information,
without any message lookahead) is far from trivial and you quickly figure
out that what is considered common or "almost standard" has no meaning for
newsreaders.
BTW, this is not unique to the newsreaders you have. Google needs to apply
even more tricks to decode ever more uncommon plain content formats and to
filter out attachments of all kinds correctly. Of course, fi you look very
close, you will notice even they cannot decode everything correctly.
Of course, as I said, if too many newsreaders don't support the current
format the web view uses to post attachments, I will switch to MIME
multipart messages. However, those are much more work to encode is you need
to support a preview and edit of such messages (which the webview does).
Thorsten
PS: Base 64 uuencoding was specified in some mid-1990s POSIX update for
standard commnad-line tools. For example GNU uudecode supports it.
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <407d8785@news.povray.org> , Darren New <dne### [at] sanrrcom> wrote:
>> Nope, Darren is wrong.
>
> Trust me. See my long rambling rant. "I tested it and it works" doesn't
> mean "it's right".
It does. You need to first understand Usenet message formats to understand
why "I tested it and it works" *does* mean "it's right". The important
thing is that "it's right" does *not* mean "everybody can parse it". And
that is the only problem.
>> Still, if many people here use odd newsreaders rather than the mainstream
>> ones, there will probably be little choice but to generate full MIME
>> messages <sigh>
>
> If you're generating the base-64 already, it's a trivial fix. All you
> have to do is put "Content-type: image/whatever" instead of
> "text/plain", and get rid of the "begin" line, and you're golden.
Believe me, I know better what is trivial to fix and what not! And your fix
it complete wrong, btw: It would make posting text together with images
impossible...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <c5k3mg$9a8$3@chho.imagico.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> uuencoded would be just fine.
It currently is uuencoded, really! Try your Linux uudecode: Start with the
begin up to the and including the ==== and pass that file to uudecode. It
will decode it without problems. And it will also encode in the same
format!
What you want is the classic uuencoding. Unfortunetly, that is more
difficult to generate and has a set of problems. Base 64 is the way to go,
but apparently to be compatiblke with the majority of newsreaders I need to
put base 64 into a MIME multipart message. This however is non-trivial and
I hoped I could avoid this work...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
