<div dir="ltr">Still, I have to put some hack inside the request constructor as it knows the content-length of the file being uploaded.<br>Also the flexi-stream could be obtained from the constructor of request via (content-stream *request*).<br>
So, yes, this task could be minimized to hacking only one place in initialize-instance of request class. I'll try it.<br><br>Thank you,<br>Andrew<br><br><div class="gmail_quote">On Fri, Sep 19, 2008 at 4:53 AM, Hans Hübner <span dir="ltr"><<a href="mailto:hans@huebner.org">hans@huebner.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">After some internal discussion, I would recommend against hacking<br>
RFC2388 - It will most likely be replaced by something which is more<br>
extensible in the future.<br>
<br>
For the time being, your easiest solution might be to use the position<br>
counter of the flexi-stream that the upload is being read from.  At<br>
the beginning of the request, you would make this stream accessible to<br>
your status handler (for example by putting it into the session), and<br>
the status handler would use the start and current position to measure<br>
request progress.<br>
<br>
Hope this still helps.  Let us know if it works or if you have found<br>
another, better solution.<br>
<font color="#888888"><br>
-Hans<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Sun, Sep 14, 2008 at 15:21, Andrei Stebakov <<a href="mailto:lispercat@gmail.com">lispercat@gmail.com</a>> wrote:<br>
> The problem is that RFC2388:READ-UNTIL-NEXT-BOUNDARY doesn't know about the<br>
> content-length as hunchentoot package doesn't pass this parameter to the<br>
> rfc2388:parse-mime function. So again it should be changed in two different<br>
> packages.<br>
> When I implemented file upload progress bar, I had to modify the hunchentoot<br>
> and rfc2388 since only hunchentoot knows about content-length and only<br>
> rfc2388 knows how many bytes was read from the stream. Using these two<br>
> parameters we can calculate the percentage  of the data that was uploaded to<br>
> the server.<br>
> I could retrieve the content-length to the client via ajax and do something<br>
> in javascript to disrupt the upload, but I doesn't look like a good solution<br>
> to me.<br>
> So, my question is where and how in hunchentoot I can raise an error so that<br>
> it would get propagated to the handler of the file upload request so that I<br>
> can show it to the user. In the request constructor (defmethod<br>
> initialize-instance ...) the body is wrapped into handler-case so any error<br>
> which occurs in it should be trapped by (error (cond) ...), right? For some<br>
> reason the error that I raise when the content-length is greater than some<br>
> number, this error gets trapped by the lisp debugger, not by (error (cond)<br>
> ...). Anyway, time for me to go back study lisp manuals! :)<br>
><br>
> Andrew<br>
><br>
> On Sun, Sep 14, 2008 at 3:14 AM, Hans Hübner <<a href="mailto:hans@huebner.org">hans@huebner.org</a>> wrote:<br>
>><br>
>> On Sun, Sep 14, 2008 at 00:55, Andrei Stebakov <<a href="mailto:lispercat@gmail.com">lispercat@gmail.com</a>><br>
>> wrote:<br>
>> > I wonder what's the best way to handle the case when a user tries to<br>
>> > upload<br>
>> > a very large file.<br>
>> > Basically we need to stop execution before it gets to the<br>
>> > parse-rfc2388-form-data and report the problem to the user.<br>
>> >[...]<br>
>> > Another thing, it's a dirty hack, what's the better way of doing this?<br>
>><br>
>> I would fix the problem in RFC2388:READ-UNTIL-NEXT-BOUNDARY.  This<br>
>> function should read the data directly to the stream provided, and it<br>
>> should have a special variable (in the RFC2388 package) that can be<br>
>> set to limit the maximum number of bytes read.<br>
>><br>
>> -Hans<br>
>> _______________________________________________<br>
>> tbnl-devel site list<br>
>> <a href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a><br>
>> <a href="http://common-lisp.net/mailman/listinfo/tbnl-devel" target="_blank">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> tbnl-devel site list<br>
> <a href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/mailman/listinfo/tbnl-devel" target="_blank">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br>
><br>
_______________________________________________<br>
tbnl-devel site list<br>
<a href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/mailman/listinfo/tbnl-devel" target="_blank">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br>
</div></div></blockquote></div><br></div>