() Sebastian Tennant
() Thu, 21 May 2009 05:22:15 +
Problem solved. With this patch applied to cgi.scm in ttn's
(www cgi) module, uploading of binary data now works with Guile
1.8.
In the end it was simply a case of splitting each part into a
header section and value section
Quoth l...@gnu.org (Ludovic Courtès):
> Hello,
>
> Sebastian Tennant writes:
>
>> Content-Disposition is mandatory, but Content-Type is optional
>> (defaulting to text/plain) as is Content-Transfer-Encoding, so the
>> "header part" of any given MIME part may be a single line or it may be
>> three.
Hello,
Sebastian Tennant writes:
> Content-Disposition is mandatory, but Content-Type is optional
> (defaulting to text/plain) as is Content-Transfer-Encoding, so the
> "header part" of any given MIME part may be a single line or it may be
> three.
Then I presume this could be read line-by-line
Quoth Sebastian Tennant :
> so the "header part" of any given MIME part may be a single line or it
> may be three.
Correction - ...it may be a single line, or it may be two, or three.
Seb
--
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
Hi Ludo,
Thanks for responding. I know this isn't really your 'thing' (for want
of a better word).
Quoth l...@gnu.org (Ludovic Courtès):
>> cgi.scm currently uses the following patterns and I can't think of an
>> alternative way of doing it:
>>
>> (let ((name-rx (make-regexp "name=\"([^\"]*
Hello,
Sebastian Tennant writes:
> cgi.scm currently uses the following patterns and I can't think of an
> alternative way of doing it:
>
> (let ((name-rx (make-regexp "name=\"([^\"]*)\""))
>(filename-rx (make-regexp "filename=\"*([^\"\r]*)\"*"))
>(type-rx (make-regexp "
Quoth Sebastian Tennant :
> Multipart/form-data comes with a Content-Length header that describes
Correction - the above should read 'CONTENT_LENGTH environment variable'.
> The boundary can be obtained from the Content-Type header and the above
Similarly, the above should read 'CONTENT_TYPE' en
Quoth Keith Wright :
>> > Restricting regexps to actual text is fine... until
>> > you need to grep binary data, or, as in this case,
>> > a combination of text and binary data.
>>
>> > in cgi.scm that extracted the uploaded (possibly
>> > binary) file, because the pattern identifying the
>> > beg
> From: Linas Vepstas
> Cc: guile-user@gnu.org
>
> 2009/5/13 Sebastian Tennant :
>
> > Restricting regexps to actual text is fine... until
> > you need to grep binary data, or, as in this case,
> > a combination of text and binary data.
>
> > in cgi.scm that extracted the uploaded (possibly
> >
2009/5/13 Sebastian Tennant :
> Restricting regexps to actual text is fine... until you need to grep
> binary data, or, as in this case, a combination of text and binary data.
Last I looked, standard c-library posix/gnu/perl/java
regex only worked on strings, not on binary data.
You'll have troub
Quoth l...@gnu.org (Ludovic Courtès):
> Hello,
>
> Sebastian Tennant writes:
>
>> (info "(guile-1.8)Regexp Functions")
>>
>> "Zero bytes (`#\nul') cannot be used in regex patterns or input
>> strings, since the underlying C functions treat that as the end of
>> string. If there's a zero byte
Quoth l...@gnu.org (Ludovic Courtès):
> Hello,
>
> Sebastian Tennant writes:
>
>> (info "(guile-1.8)Regexp Functions")
>>
>> "Zero bytes (`#\nul') cannot be used in regex patterns or input
>> strings, since the underlying C functions treat that as the end of
>> string. If there's a zero byte
Hello,
Sebastian Tennant writes:
> (info "(guile-1.8)Regexp Functions")
>
> "Zero bytes (`#\nul') cannot be used in regex patterns or input
> strings, since the underlying C functions treat that as the end of
> string. If there's a zero byte an error is thrown."
I think it makes sense to
Quoth Thien-Thi Nguyen :
> Perhaps you can convert the string in variable `upload' to a uniform
> vector and write it out using `uniform-vector-write'. It may be the
> case, too, that the string can be passed to `uniform-vector-write'
> directly
I've isolated the problem.
(info "(guile-1.8)Regex
Quoth l...@gnu.org (Ludovic Courtès):
> Sebastian Tennant writes:
>
>> (define (upload name)
>>(and=> (uploads name) car))
>
> [...]
>
>> P.S. Documentation bug - the procedure 'and=>' is missing from the
>> manual. What's the difference between the way the upload procedure
>> is w
Sebastian Tennant writes:
> (define (upload name)
>(and=> (uploads name) car))
[...]
> P.S. Documentation bug - the procedure 'and=>' is missing from the
> manual. What's the difference between the way the upload procedure
> is written above and simply:
>
> (define (upload
Quoth Thien-Thi Nguyen :
> () Sebastian Tennant
> () Sun, 10 May 2009 16:21:29 +
>
> (with-output-to-file (string-append USER-UPLOAD-DIR upload-fname)
> (lambda ()
> (display upload)))
>
> Perhaps you can convert the string in variable `upload' to a uniform vector
> and
() Sebastian Tennant
() Sun, 10 May 2009 16:21:29 +
(with-output-to-file (string-append USER-UPLOAD-DIR upload-fname)
(lambda ()
(display upload)))
Perhaps you can convert the string in variable `upload' to a uniform vector
and write it out using `uniform-vector-write
Thien-Thi Nguyen writes:
> FWIW, Guile 1.4.x can:
>
> string> (string #\nul)
> "^@"
Actually, it works as well with 1.8:
--8<---cut here---start->8---
guile> (string #\nul)
$1 = "\x00"
--8<---cut here---end--->8---
The "st
() l...@gnu.org (Ludovic Courtès)
() Mon, 11 May 2009 17:11:40 +0200
The problem is that Guile strings cannot contain null characters.
FWIW, Guile 1.4.x can:
string> (string #\nul)
"^@"
It may be a design flaw in Guile-WWW, which abuses strings to
store binary data.
I see it rather as
Hello,
Sebastian Tennant writes:
> string contains #\nul character: "\x0d
The problem is that Guile strings cannot contain null characters. For
arbitrary binary data, other containers must be used, such as SRFI-4
u8vectors or R6RS bytevectors (from Guile-R6RS-Libs).
It may be a design flaw i
Hi Guilers,
The following works fine for plain text files but fails with Word
documents, PDFs, PNG files and no doubt other (binary?) file types.
This error msg, followed by the contents of the file, is dumped on
stderr each time:
string contains #\nul character: "\x0d
Content-Disposition: for
22 matches
Mail list logo
