[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Lynx-dev] HTML Forms > Fileupload (RFC1867) > Content-Type
From: |
s . marek |
Subject: |
[Lynx-dev] HTML Forms > Fileupload (RFC1867) > Content-Type |
Date: |
Wed, 7 Nov 2007 10:40:59 +0100 |
Hi,
when loading up a file to a webserver via an HTML Form, RFC 1867 suggests,
that you set the Content-Type of the mime-part of the file to
application/octet-stream, if the media-type is unknown. (see sections 3.3
and 7 in RFC 1867)
Lynx uses Content-Type: text/plain, when no suffix is matching. I have to
admit, that the RFC is a bit unclear in section 7 about what the default
Content-Type actually is, but IMHO it should default to the binary type
(section 3.3 is clearer).
--- src/GridText.c.old 2007-11-07 09:19:03.000000000 +0100
+++ src/GridText.c 2007-11-07 09:20:53.000000000 +0100
@@ -10342,7 +10342,7 @@
return (format != 0 && non_empty(format->name))
? format->name
- : "text/plain";
+ : "application/octet-stream";
}
#endif /* USE_FILE_UPLOAD */
This is a patch against lynx2.8.6rel.4 - so the line-numbers may differ in
2.8.7. The affected function is
static const char *guess_content_type(const char *filename) in
src/GridText.c.
I worked around my local problem without recompiling lynx by adding an
extra SUFFIX-line in lynx.cfg for my special file here, which has the
extension .image and needs to be treated as application/octet-stream. But
I think the root of the problem is the wrong default Content-Type. It
should have worked right out-of-the-box.
Hope I haven't overlooked anything,
Sebastian.
- [Lynx-dev] HTML Forms > Fileupload (RFC1867) > Content-Type,
s . marek <=