httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: segfault in Apache::Upload::fh with libapreq 1.1rc2
Date Mon, 06 Jan 2003 16:38:15 GMT
Sven Geisler <> writes:

> Am Mon, 2003-01-06 um 15.55 schrieb Joe Schaefer:
> > 
> > BTW: upload->size should be safe to test in this situation.
> But what is in a case if the user uploads a file with zero bytes.
> I think this should be handle by the application logic.

In libapreq, we don't do anything special to differentiate
between 0 byte files and blank upload form widgets.  Testing
the result of upload->fh in this situation will depend on
your use of UPLOAD_HOOK.  That's not goodness.

Unfortunately, I don't know the Right Answer for this issue,
but here are some issues libapreq has to deal with.

One potential differentiator would be the contents of 
upload->filename, but this is *unreliable*.  Browsers 
are not required to supply a file *name* along with the 
file contents.

Also, HTML4-based browsers are allowed to completely 
ignore the <input type="file"...> form widget 
when constructing the POST data (assuming the user 
left it blank).  From Section 17.13.2 of the latest 
HTML spec: 

  If a control doesn't have a current value when the form
  is submitted, user agents are not required to treat it 
  as a successful control.

So basically what I'm saying is this: AFAICT there's 
no reliable way for libapreq to tell the difference 
between an empty file and a blank form widget. We
should make the behavior of $upload->fh more uniform,
but to me, that'd mean running the hook once in
for the zero-byte case.  This would be a nontrivial 
change in the behavior of libapreq, so it might be
better to schedule this change for the next release.

In the next release, we're going to add a "nargs" field 
to the apache_request_t, which'll break libapreq's ABI.  
IMO that'd be a good time to incorporate such improvements.

Joe Schaefer

View raw message