You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@ebuilt.com> on 2000/11/10 22:20:52 UTC
[PATCH] check Expect after post_read_request
Expect is an annoying header field, added to HTTP in RFC 2616, that
requires an error response if it contains an extension token that
the server does not understand. Unfortunately, we check it before
we give any of the modules a chance to see and "handle" such an
extension. This moves the check after post_read_request.
I can't imagine this breaking anything, but let me know if you do.
The patch is against 1.3, but probably applies to 2.0 as well.
The author is Justin Erenkrantz <je...@ebuilt.com>.
....Roy
Index: http_protocol.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.292
diff -u -r1.292 http_protocol.c
--- http_protocol.c 2000/11/06 22:05:13 1.292
+++ http_protocol.c 2000/11/11 05:06:21
@@ -1124,6 +1124,13 @@
ap_log_transaction(r);
return r;
}
+
+ if ((access_status = ap_run_post_read_request(r))) {
+ ap_die(access_status, r);
+ ap_log_transaction(r);
+ return NULL;
+ }
+
if (((expect = ap_table_get(r->headers_in, "Expect")) != NULL) &&
(expect[0] != '\0')) {
/*
@@ -1145,12 +1152,6 @@
ap_log_transaction(r);
return r;
}
- }
-
- if ((access_status = ap_run_post_read_request(r))) {
- ap_die(access_status, r);
- ap_log_transaction(r);
- return NULL;
}
return r;
Re: [PATCH] check Expect after post_read_request
Posted by rb...@covalent.net.
On Fri, 10 Nov 2000, Roy T. Fielding wrote:
> > Is this done better by input filters in 2.0? I'm just asking here,
>
> Maybe. The tricky part is when the check is done. It has to be after
> any extensions (input filters or regular modules) have had a chance to
> check Expect and remove anything that they will handle, but before any
> method is applied to a resource. I haven't looked at where I would
> place it in the current 2.0 tree.
Okay. I want to think about this for a day or two before I give my
opinion, because I am very torn about this. My gut is that Expect headers
should be handled by input filters. But then I have to wonder if that is
too complex for a simple header parser. hmmmm
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] check Expect after post_read_request
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Is this done better by input filters in 2.0? I'm just asking here,
Maybe. The tricky part is when the check is done. It has to be after
any extensions (input filters or regular modules) have had a chance to
check Expect and remove anything that they will handle, but before any
method is applied to a resource. I haven't looked at where I would
place it in the current 2.0 tree.
....Roy
Re: [PATCH] check Expect after post_read_request
Posted by rb...@covalent.net.
On Fri, 10 Nov 2000, Roy T. Fielding wrote:
> Expect is an annoying header field, added to HTTP in RFC 2616, that
> requires an error response if it contains an extension token that
> the server does not understand. Unfortunately, we check it before
> we give any of the modules a chance to see and "handle" such an
> extension. This moves the check after post_read_request.
>
> I can't imagine this breaking anything, but let me know if you do.
> The patch is against 1.3, but probably applies to 2.0 as well.
> The author is Justin Erenkrantz <je...@ebuilt.com>.
>
> ....Roy
Is this done better by input filters in 2.0? I'm just asking here,
because I have mixed feelings and can be convinced either way quite
easily.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------