You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Nce Rt <nc...@yahoo.com> on 2013/03/05 00:50:06 UTC
[users@httpd] unknown 401 entity from apache
Environment:
Platform- linux
Apache version- 2.2
Modules enabled- deflate dir autoindex env mime negotiation custom_module reqtimeout setenvif
As you can see, both auth and authz are disabled completely. httpd.conf and apache2.conf files reflect the same. In handling some proprietary authentication protocol in my custom_module, I do return 401 status code along with a custom entity which goes thro' fine to the client. But when I send a second 401 status return (required by my own auth protocol) along with a custom entity, client do get the 401 status but a different entity below which I don't send:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>401 Authorization Required</title></head><body><h1>Authorization Required</h1><p>This server could not verify that youare authorized to access the documentrequested. Either you supplied the wrongcredentials (e.g., bad password), or yourbrowser doesn't understand how to supplythe credentials required.</p></body></html>
The entity I put doesn't get sent out the client but the above. I've not defined any ErrorDocument directive with the above message. Any clues?
Re: [users@httpd] unknown 401 entity from apache
Posted by Eric Covener <co...@gmail.com>.
On Mon, Mar 4, 2013 at 6:50 PM, Nce Rt <nc...@yahoo.com> wrote:
> Environment:
> Platform- linux
> Apache version- 2.2
> Modules enabled- deflate dir autoindex env mime negotiation
> custom_module reqtimeout setenvif
>
> As you can see, both auth and authz are disabled completely. httpd.conf and
> apache2.conf files reflect the same. In handling some proprietary
> authentication protocol in my custom_module, I do return 401 status code
> along with a custom entity which goes thro' fine to the client. But when I
> send a second 401 status return (required by my own auth protocol) along
> with a custom entity, client do get the 401 status but a different entity
> below which I don't send:
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>401
> Authorization Required</title></head><body><h1>Authorization
> Required</h1><p>This server could not verify that youare authorized to
> access the documentrequested. Either you supplied the wrongcredentials
> (e.g., bad password), or yourbrowser doesn't understand how to supplythe
> credentials required.</p></body></html>
>
> The entity I put doesn't get sent out the client but the above. I've not
> defined any ErrorDocument directive with the above message. Any clues?
Better on modules-dev@. Does one call return 401 and another return
DONE and set r->status=401? What hook and what do you return?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
The handler here is a custom handler written by me.
How does one retrieve the Scheme from the incoming request in such user written handlers?
________________________________
From: Issac Goldstand <ma...@beamartyr.net>
To: modules-dev@httpd.apache.org
Sent: Thursday, March 7, 2013 12:09 AM
Subject: Re: some key fields of request_rec are null
On 06/03/2013 23:21, Nce Rt wrote:
>
>
> A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
> r->content_type, r->parsed_uri.scheme
>
> the http request on the wire has the content_type header set.
>
> r->parsed_uri.path is not null though.
>
>
> apache is configured as reverse proxy here.
>
Hi Nce
1) You didn't say what handler - I assume you mean the default response
handler
2) Although request_rec might be misleading these days with many
server-side frameworks distinguishing between "Response" and "Request"
objects, it doesn't quite work that way in Apache; the request_rec has
worked pretty much the way it does for a loooooooong time. So
r->content_type is actually used to set the *response* content type.
You might want to get Content-Type from r->headers_in
All the best,
Issac
Re: ap_log_rerror limit size
Posted by Hoang-Vu Dang <da...@gmail.com>.
well, I do not buy the idea of security reasons, but I agree with your last
sentence that they do not see the need to make this a configurable option,
the error log does not need it.
regarding my purpose: mod_dumpio dumps data into the error log file in
chunks, I want to merge them if the message is large and do something with
it before logging. With this limitation, I will need to write it to
somewhere else using my custom file handler.
Vu
On Wed, Mar 13, 2013 at 5:46 PM, <rm...@seid-online.de> wrote:
> On Wed, Mar 13, 2013 at 04:40:50PM +0100, Hoang-Vu Dang wrote:
> > I traced this into the Apache source code (ver 2.4.4). It looks like the
> > error message string is really limited by the size of 8KB.
> >
> > This line is in server/log.c:1097
> >
> > "
> > static void log_error_core(const char *file, int line, int module_index,
> > int level,
> > apr_status_t status, const server_rec *s,
> > const conn_rec *c,
> > const request_rec *r, apr_pool_t *pool,
> > const char *fmt, va_list args)
> > {
> > char errstr[MAX_STRING_LEN];
> > "
> >
> > "
> > And MAX_STRING_LEN is defined in include/httpd.h:298
> >
> > /** The default string length */
> > #define MAX_STRING_LEN HUGE_STRING_LEN
> >
> > /** The length of a Huge string */
> > #define HUGE_STRING_LEN 8192
> > "
> >
> > I tried to increase this value, recompile, and apparently I got a longer
> > message.
> > Please correct me if I am wrong... If this is true then can anyone tell
> me
> > why this "HUGE_STRING_LEN" value is a hard-coded value but not a
> > configurable option ?
>
> I can't speak for the apache core team, but such a limit usually is done
> for security reasons. Tracking buffer overflows in dynamically allocated
> memory can be rather tricky. Btw, what's your goal here? I get the
> feeling that you try to (ab)use the error log as a place to dump large
> blobs of information (traces?). Remember, this is an error log, not a
> place to dump Tolstoy's War and Peace ....
>
> HTH Ralf Mattes
>
>
> > Cheers, Vu
> that you try to (ab)use the error log as a place to dump large blobs of
> information (traces?). Remember, this is an error log, not a
> place to dump Tolstoy's War and Peace ....
>
> HTH Ralf Mattes
> >
> >
> > On 03/13/2013 11:16 AM, Eric Covener wrote:
> >> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang <da...@gmail.com>
> wrote:
> >>> Hi guys,
> >>>
> >>> Is there any limit of the size of a message log entry? How to control
> >>> this ?
> >>>
> >>> I did this:
> >>>
> >>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
> >>> "%s", buffer);
> >>>
> >>> And the buffer was truncated on the error log. I check the strlen of
> the
> >>> buffer and it was about 320K, and I got only around: ~ 8KB
> >> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
> >> with other entries. Are you sure it's truncated and not just spread
> >> out?
>
Re: ap_log_rerror limit size
Posted by rm...@seid-online.de.
On Wed, Mar 13, 2013 at 04:40:50PM +0100, Hoang-Vu Dang wrote:
> I traced this into the Apache source code (ver 2.4.4). It looks like the
> error message string is really limited by the size of 8KB.
>
> This line is in server/log.c:1097
>
> "
> static void log_error_core(const char *file, int line, int module_index,
> int level,
> apr_status_t status, const server_rec *s,
> const conn_rec *c,
> const request_rec *r, apr_pool_t *pool,
> const char *fmt, va_list args)
> {
> char errstr[MAX_STRING_LEN];
> "
>
> "
> And MAX_STRING_LEN is defined in include/httpd.h:298
>
> /** The default string length */
> #define MAX_STRING_LEN HUGE_STRING_LEN
>
> /** The length of a Huge string */
> #define HUGE_STRING_LEN 8192
> "
>
> I tried to increase this value, recompile, and apparently I got a longer
> message.
> Please correct me if I am wrong... If this is true then can anyone tell me
> why this "HUGE_STRING_LEN" value is a hard-coded value but not a
> configurable option ?
I can't speak for the apache core team, but such a limit usually is done
for security reasons. Tracking buffer overflows in dynamically allocated
memory can be rather tricky. Btw, what's your goal here? I get the
feeling that you try to (ab)use the error log as a place to dump large
blobs of information (traces?). Remember, this is an error log, not a
place to dump Tolstoy's War and Peace ....
HTH Ralf Mattes
> Cheers, Vu
that you try to (ab)use the error log as a place to dump large blobs of
information (traces?). Remember, this is an error log, not a
place to dump Tolstoy's War and Peace ....
HTH Ralf Mattes
>
>
> On 03/13/2013 11:16 AM, Eric Covener wrote:
>> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang <da...@gmail.com> wrote:
>>> Hi guys,
>>>
>>> Is there any limit of the size of a message log entry? How to control
>>> this ?
>>>
>>> I did this:
>>>
>>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
>>> "%s", buffer);
>>>
>>> And the buffer was truncated on the error log. I check the strlen of the
>>> buffer and it was about 320K, and I got only around: ~ 8KB
>> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
>> with other entries. Are you sure it's truncated and not just spread
>> out?
Re: ap_log_rerror limit size
Posted by Hoang-Vu Dang <da...@gmail.com>.
I traced this into the Apache source code (ver 2.4.4). It looks like the
error message string is really limited by the size of 8KB.
This line is in server/log.c:1097
"
static void log_error_core(const char *file, int line, int module_index,
int level,
apr_status_t status, const server_rec *s,
const conn_rec *c,
const request_rec *r, apr_pool_t *pool,
const char *fmt, va_list args)
{
char errstr[MAX_STRING_LEN];
"
"
And MAX_STRING_LEN is defined in include/httpd.h:298
/** The default string length */
#define MAX_STRING_LEN HUGE_STRING_LEN
/** The length of a Huge string */
#define HUGE_STRING_LEN 8192
"
I tried to increase this value, recompile, and apparently I got a longer
message.
Please correct me if I am wrong... If this is true then can anyone tell
me why this "HUGE_STRING_LEN" value is a hard-coded value but not a
configurable option ?
Cheers, Vu
On 03/13/2013 11:16 AM, Eric Covener wrote:
> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang <da...@gmail.com> wrote:
>> Hi guys,
>>
>> Is there any limit of the size of a message log entry? How to control this ?
>>
>> I did this:
>>
>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
>> "%s", buffer);
>>
>> And the buffer was truncated on the error log. I check the strlen of the buffer and it was about 320K, and I got only around: ~ 8KB
> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
> with other entries. Are you sure it's truncated and not just spread
> out?
Re: ap_log_rerror limit size
Posted by Eric Covener <co...@gmail.com>.
On Wed, Mar 13, 2013 at 6:16 AM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang <da...@gmail.com> wrote:
>> Hi guys,
>>
>> Is there any limit of the size of a message log entry? How to control this ?
>>
>> I did this:
>>
>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
>> "%s", buffer);
>>
>> And the buffer was truncated on the error log. I check the strlen of the buffer and it was about 320K, and I got only around: ~ 8KB
>
> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
> with other entries. Are you sure it's truncated and not just spread
> out?
Er if using a piped logger that is.
Re: ap_log_rerror limit size
Posted by Hoang Vu Dang <da...@gmail.com>.
Yes I am sure I can't find other entries related to that request.
How to find whether I used PIPE_BUF and how to increase that BUF size ?
On Mar 13, 2013, at 11:16 AM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang <da...@gmail.com> wrote:
>> Hi guys,
>>
>> Is there any limit of the size of a message log entry? How to control this ?
>>
>> I did this:
>>
>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
>> "%s", buffer);
>>
>> And the buffer was truncated on the error log. I check the strlen of the buffer and it was about 320K, and I got only around: ~ 8KB
>
> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
> with other entries. Are you sure it's truncated and not just spread
> out?
Re: ap_log_rerror limit size
Posted by Eric Covener <co...@gmail.com>.
On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang <da...@gmail.com> wrote:
> Hi guys,
>
> Is there any limit of the size of a message log entry? How to control this ?
>
> I did this:
>
> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
> "%s", buffer);
>
> And the buffer was truncated on the error log. I check the strlen of the buffer and it was about 320K, and I got only around: ~ 8KB
If it's more than PIPE_BUF, it won't be atomic and can be interleaved
with other entries. Are you sure it's truncated and not just spread
out?
ap_log_rerror limit size
Posted by Hoang Vu Dang <da...@gmail.com>.
Hi guys,
Is there any limit of the size of a message log entry? How to control this ?
I did this:
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
"%s", buffer);
And the buffer was truncated on the error log. I check the strlen of the buffer and it was about 320K, and I got only around: ~ 8KB
Thank, Vu
Re: some key fields of request_rec are null
Posted by Tom Evans <te...@googlemail.com>.
On Tue, Mar 12, 2013 at 8:04 PM, Nce Rt <nc...@yahoo.com> wrote:
> here is one of the past emails:
> On Wed, Mar 6, 2013 at 4:21 PM, Nce Rt <nc...@yahoo.com> wrote:
>>
>>
>> A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
>> r->content_type, r->parsed_uri.scheme
>
>
> instead of being a moronic moaner, make some common-sensical assumptions if you really know what you're talking about.
>
There are many different handler phases, all of which you can set your
module to APR_HOOK_FIRST into. You haven't said if this is a content
handler, a fixup handler, etc. If you hook in to post_read_request,
then duh, most of the fields on request_rec are not populated.
But you know all that already, I'm just a moronic moaner, so I'll
leave you to your anger. I'm sure insulting people will eventually
lead you to the correct method.
Re: some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
here is one of the past emails:
On Wed, Mar 6, 2013 at 4:21 PM, Nce Rt <nc...@yahoo.com> wrote:
>
>
> A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
> r->content_type, r->parsed_uri.scheme
instead of being a moronic moaner, make some common-sensical assumptions if you really know what you're talking about.
________________________________
From: Tom Evans <te...@googlemail.com>
To: modules-dev@httpd.apache.org; Nce Rt <nc...@yahoo.com>
Sent: Tuesday, March 12, 2013 2:59 AM
Subject: Re: some key fields of request_rec are null
On Mon, Mar 11, 2013 at 7:47 PM, Nce Rt <nc...@yahoo.com> wrote:
> that's what is null I've been talking about past 2 weeks!!
>
You still haven't confirmed what handler you are running in. Certain
parts of the request_rec are populated by different handler stages, if
your handler is running before they run, then (surprise!) those parts
of the config won't be filled in.
You've been asked several times what handler your code is running in,
providing context and/or code would be better than just moaning.
Cheers
Tom
Re: some key fields of request_rec are null
Posted by Tom Evans <te...@googlemail.com>.
On Mon, Mar 11, 2013 at 7:47 PM, Nce Rt <nc...@yahoo.com> wrote:
> that's what is null I've been talking about past 2 weeks!!
>
You still haven't confirmed what handler you are running in. Certain
parts of the request_rec are populated by different handler stages, if
your handler is running before they run, then (surprise!) those parts
of the config won't be filled in.
You've been asked several times what handler your code is running in,
providing context and/or code would be better than just moaning.
Cheers
Tom
Re: some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
that's what is null I've been talking about past 2 weeks!!
________________________________
From: Issac Goldstand <ma...@beamartyr.net>
To: Nce Rt <nc...@yahoo.com>
Cc: modules-dev@httpd.apache.org
Sent: Sunday, March 10, 2013 12:54 AM
Subject: Re: some key fields of request_rec are null
Unicasting is ok, but risky - I often lose lots of unicasts to spam, and
then there's no list to back me up :)
Also, then other folks in the future don't get their answers...
r->parsed_uri->scheme
http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html
Issac
On 08/03/2013 21:16, Nce Rt wrote:
> I am unicasting because I didn't hear from others for multiple postings.
> feels like spamming the list.
>
> I am still trying to figure out how to get the Scheme (like http,
> https,..) info from the incoming request in a custom handler function.
>
> ------------------------------------------------------------------------
> *From:* Issac Goldstand <ma...@beamartyr.net>
> *To:* modules-dev@httpd.apache.org
> *Sent:* Thursday, March 7, 2013 12:09 AM
> *Subject:* Re: some key fields of request_rec are null
>
> On 06/03/2013 23:21, Nce Rt wrote:
> >
> >
> > A custom handler which is registered to run APR_HOOK_FIRST has these
> fields null when processing http request:
> > r->content_type, r->parsed_uri.scheme
> >
> > the http request on the wire has the content_type header set.
> >
> > r->parsed_uri.path is not null though.
> >
> >
> > apache is configured as reverse proxy here.
> >
>
> Hi Nce
>
> 1) You didn't say what handler - I assume you mean the default response
> handler
> 2) Although request_rec might be misleading these days with many
> server-side frameworks distinguishing between "Response" and "Request"
> objects, it doesn't quite work that way in Apache; the request_rec has
> worked pretty much the way it does for a loooooooong time. So
> r->content_type is actually used to set the *response* content type.
> You might want to get Content-Type from r->headers_in
>
> All the best,
> Issac
>
>
Re: some key fields of request_rec are null
Posted by Issac Goldstand <ma...@beamartyr.net>.
Unicasting is ok, but risky - I often lose lots of unicasts to spam, and
then there's no list to back me up :)
Also, then other folks in the future don't get their answers...
r->parsed_uri->scheme
http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html
Issac
On 08/03/2013 21:16, Nce Rt wrote:
> I am unicasting because I didn't hear from others for multiple postings.
> feels like spamming the list.
>
> I am still trying to figure out how to get the Scheme (like http,
> https,..) info from the incoming request in a custom handler function.
>
> ------------------------------------------------------------------------
> *From:* Issac Goldstand <ma...@beamartyr.net>
> *To:* modules-dev@httpd.apache.org
> *Sent:* Thursday, March 7, 2013 12:09 AM
> *Subject:* Re: some key fields of request_rec are null
>
> On 06/03/2013 23:21, Nce Rt wrote:
> >
> >
> > A custom handler which is registered to run APR_HOOK_FIRST has these
> fields null when processing http request:
> > r->content_type, r->parsed_uri.scheme
> >
> > the http request on the wire has the content_type header set.
> >
> > r->parsed_uri.path is not null though.
> >
> >
> > apache is configured as reverse proxy here.
> >
>
> Hi Nce
>
> 1) You didn't say what handler - I assume you mean the default response
> handler
> 2) Although request_rec might be misleading these days with many
> server-side frameworks distinguishing between "Response" and "Request"
> objects, it doesn't quite work that way in Apache; the request_rec has
> worked pretty much the way it does for a loooooooong time. So
> r->content_type is actually used to set the *response* content type.
> You might want to get Content-Type from r->headers_in
>
> All the best,
> Issac
>
>
Re: some key fields of request_rec are null
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 06/03/2013 23:21, Nce Rt wrote:
>
>
> A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
> r->content_type, r->parsed_uri.scheme
>
> the http request on the wire has the content_type header set.
>
> r->parsed_uri.path is not null though.
>
>
> apache is configured as reverse proxy here.
>
Hi Nce
1) You didn't say what handler - I assume you mean the default response
handler
2) Although request_rec might be misleading these days with many
server-side frameworks distinguishing between "Response" and "Request"
objects, it doesn't quite work that way in Apache; the request_rec has
worked pretty much the way it does for a loooooooong time. So
r->content_type is actually used to set the *response* content type.
You might want to get Content-Type from r->headers_in
All the best,
Issac
Re: apache GUI frontend to edit config files
Posted by Eric Covener <co...@gmail.com>.
On Mon, Mar 11, 2013 at 6:07 PM, Nce Rt <nc...@yahoo.com> wrote:
>
> Is there a GUI tool available to configure and control httpd server? Like editing httpd.conf files, restart server, enable/disable modules, etc from UI.
There are some unpopular ones, and more "web control panel" hosting
frontends. Off-topic here, though.
Re: How to control block size of input_filter data
Posted by Sorin Manolache <so...@gmail.com>.
On 2013-03-12 10:52, Hoang-Vu Dang wrote:
> Thank you for the quick reply !
>
> The context is what I am looking into right now, and It is indeed a
> right solution to my original question. I just want to know a little bit
> more detail if you do not mind, you said:
>
> "I typically destroy it by placing a callback in the cleanup hook of the
> req->pool. "
Now I remember: I use C++ so I need to create and destroy the context.
But if you allocate your context from an apr_pool you don't need to
bother about the context destruction because it is automatically
destroyed. Sorry for confusing you.
Just for information, I create/destroy the contexts like that:
int
flt_init_function(ap_filter_t *flt) {
// I use C++, if you allocated ctx from a pool, you don't even need
this callback destruction
flt->ctx = new MyContext();
// delete_ctx is called when r->pool is destroyed, i.e. at the very
end of the request processing, after the response has been sent to the
client and the request logged.
apr_pool_cleanup_register(flt->r->pool, flt->ctx, (apr_status_t
(*)(void *))destroy_ctx, apr_pool_cleanup_null);
}
and
apr_status_t
destroy_ctx(MyContext *ctx) {
delete ctx;
return APR_SUCCESS;
}
The filter function could be something like:
apr_status_t
input_filter(ap_filter_t *f, apr_bucket_brigade *bb, ap_input_mode_t
mode, apr_read_type_e block, apr_off_t bytes) {
MyContext *ctx = (MyContext *)f->ctx;
switch (ctx->state()) {
case FIRST_INVOKATION:
...
break;
case NTH_INVOKATION:
...
break;
case FOUND_EOS:
...
break;
...
}
}
>
> What exactly is the callback function that I need to look for ? When it
> executes, can we be sure that all the data has been processed, and our
> ctx will be maintained at that state ?
>
> Best, Vu
>
> On 03/12/2013 10:36 AM, Sorin Manolache wrote:
>> On 2013-03-12 10:16, Hoang-Vu Dang wrote:
>>> Hi all,
>>>
>>> When I write an input_filter, I notice that the data sent from client is
>>> not always available in one chunk if it's large.
>>>
>>> In other words, The input_filter() function will be called multiple
>>> times per request. My question is how to have a control on this (for
>>> example the size of the chunk until it breaks in to two) ? what should
>>> we look into in order to check if the two filters are called from the
>>> same request.
>>>
>>
>> You can keep the state from one filter invokation to the other in
>> f->ctx, the filter's context.
>>
>> There are many ways to do this.
>>
>> One way I've seen is to check if f->ctx is NULL (if it was NULL then
>> it would mean that it is the first invokation of the filter). If it's
>> NULL, we build the context. Subsequent invokations have the context !=
>> NULL. You'll have to destroy the context at the end of the request. I
>> typically destroy it by placing a callback in the cleanup hook of the
>> req->pool.
>>
>> Another way to destroy it, but in my opinion a wrong way, is to
>> destroy it when you encounter EOS in the data processed by the filter.
>> I'd say it's wrong because a wrongly written filter could send data
>> _after_ an EOS bucket and then you could not distinguish between a new
>> request and a request sending data after EOS.
>>
>> Another way to initialize the context is by placing a filter init
>> function when you declare the filter and to initialize the context in
>> this function. This is more elegant in my opinion, because the context
>> is already initialized when the filter is called the first time.
>>
>> The filter context could be any structure, so you can track the filter
>> processing state in it.
>>
>> Regards,
>> Sorin
>>
Re: How to control block size of input_filter data
Posted by Hoang-Vu Dang <da...@gmail.com>.
Thank you for the quick reply !
The context is what I am looking into right now, and It is indeed a
right solution to my original question. I just want to know a little bit
more detail if you do not mind, you said:
"I typically destroy it by placing a callback in the cleanup hook of the
req->pool. "
What exactly is the callback function that I need to look for ? When it
executes, can we be sure that all the data has been processed, and our
ctx will be maintained at that state ?
Best, Vu
On 03/12/2013 10:36 AM, Sorin Manolache wrote:
> On 2013-03-12 10:16, Hoang-Vu Dang wrote:
>> Hi all,
>>
>> When I write an input_filter, I notice that the data sent from client is
>> not always available in one chunk if it's large.
>>
>> In other words, The input_filter() function will be called multiple
>> times per request. My question is how to have a control on this (for
>> example the size of the chunk until it breaks in to two) ? what should
>> we look into in order to check if the two filters are called from the
>> same request.
>>
>
> You can keep the state from one filter invokation to the other in
> f->ctx, the filter's context.
>
> There are many ways to do this.
>
> One way I've seen is to check if f->ctx is NULL (if it was NULL then
> it would mean that it is the first invokation of the filter). If it's
> NULL, we build the context. Subsequent invokations have the context !=
> NULL. You'll have to destroy the context at the end of the request. I
> typically destroy it by placing a callback in the cleanup hook of the
> req->pool.
>
> Another way to destroy it, but in my opinion a wrong way, is to
> destroy it when you encounter EOS in the data processed by the filter.
> I'd say it's wrong because a wrongly written filter could send data
> _after_ an EOS bucket and then you could not distinguish between a new
> request and a request sending data after EOS.
>
> Another way to initialize the context is by placing a filter init
> function when you declare the filter and to initialize the context in
> this function. This is more elegant in my opinion, because the context
> is already initialized when the filter is called the first time.
>
> The filter context could be any structure, so you can track the filter
> processing state in it.
>
> Regards,
> Sorin
>
Re: How to control block size of input_filter data
Posted by Sorin Manolache <so...@gmail.com>.
On 2013-03-12 10:16, Hoang-Vu Dang wrote:
> Hi all,
>
> When I write an input_filter, I notice that the data sent from client is
> not always available in one chunk if it's large.
>
> In other words, The input_filter() function will be called multiple
> times per request. My question is how to have a control on this (for
> example the size of the chunk until it breaks in to two) ? what should
> we look into in order to check if the two filters are called from the
> same request.
>
You can keep the state from one filter invokation to the other in
f->ctx, the filter's context.
There are many ways to do this.
One way I've seen is to check if f->ctx is NULL (if it was NULL then it
would mean that it is the first invokation of the filter). If it's NULL,
we build the context. Subsequent invokations have the context != NULL.
You'll have to destroy the context at the end of the request. I
typically destroy it by placing a callback in the cleanup hook of the
req->pool.
Another way to destroy it, but in my opinion a wrong way, is to destroy
it when you encounter EOS in the data processed by the filter. I'd say
it's wrong because a wrongly written filter could send data _after_ an
EOS bucket and then you could not distinguish between a new request and
a request sending data after EOS.
Another way to initialize the context is by placing a filter init
function when you declare the filter and to initialize the context in
this function. This is more elegant in my opinion, because the context
is already initialized when the filter is called the first time.
The filter context could be any structure, so you can track the filter
processing state in it.
Regards,
Sorin
How to control block size of input_filter data
Posted by Hoang-Vu Dang <da...@gmail.com>.
Hi all,
When I write an input_filter, I notice that the data sent from client is
not always available in one chunk if it's large.
In other words, The input_filter() function will be called multiple
times per request. My question is how to have a control on this (for
example the size of the chunk until it breaks in to two) ? what should
we look into in order to check if the two filters are called from the
same request.
Thanks, Vu
Re: apache GUI frontend to edit config files
Posted by Issac Goldstand <ma...@beamartyr.net>.
There's webmin...
On 12/03/2013 00:07, Nce Rt wrote:
>
>
> Is there a GUI tool available to configure and control httpd server? Like editing httpd.conf files, restart server, enable/disable modules, etc from UI.
>
apache GUI frontend to edit config files
Posted by Nce Rt <nc...@yahoo.com>.
Is there a GUI tool available to configure and control httpd server? Like editing httpd.conf files, restart server, enable/disable modules, etc from UI.
Re: state management in handlers
Posted by Joe Lewis <jl...@silverhawk.net>.
Probably not, because you will have to cater to the MPM - e.g. use shared
memory if a subsequent request comes into a different process.
I'd suggest using shared memory (there are apr routines to do that), and
that should guarantee that state will be shared between different threads
or processes.
Joe
On Wed, Mar 6, 2013 at 5:59 PM, Nce Rt <nc...@yahoo.com> wrote:
> Is there a sample code to store and retrieve the state in a custom
> handler's local session?
Re: state management in handlers
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 07/03/2013 02:59, Nce Rt wrote:
> Is there a sample code to store and retrieve the state in a custom handler's local session?
>
Look at r->notes
state management in handlers
Posted by Nce Rt <nc...@yahoo.com>.
Is there a sample code to store and retrieve the state in a custom handler's local session?
Re: some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
I guess I shouldn't have just relied on the code comments in httpd.h(ver 2.2) for this field:
/** The content-type for the current request */
const char *content_type;
Thanks again.
________________________________
From: Eric Covener <co...@gmail.com>
To: modules-dev@httpd.apache.org; Nce Rt <nc...@yahoo.com>
Sent: Wednesday, March 6, 2013 4:23 PM
Subject: Re: some key fields of request_rec are null
On Wed, Mar 6, 2013 at 6:34 PM, Nce Rt <nc...@yahoo.com> wrote:
> It's request_rec which represents http Request not Response. look into this data structure for the content-type field.
That's not how the field is used. If you want to read a Content-Type
request header, read it from r->headers_in.
Re: some key fields of request_rec are null
Posted by Eric Covener <co...@gmail.com>.
On Wed, Mar 6, 2013 at 6:34 PM, Nce Rt <nc...@yahoo.com> wrote:
> It's request_rec which represents http Request not Response. look into this data structure for the content-type field.
That's not how the field is used. If you want to read a Content-Type
request header, read it from r->headers_in.
Re: some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
It's request_rec which represents http Request not Response. look into this data structure for the content-type field.
________________________________
From: Eric Covener <co...@gmail.com>
To: modules-dev@httpd.apache.org; Nce Rt <nc...@yahoo.com>
Sent: Wednesday, March 6, 2013 2:50 PM
Subject: Re: some key fields of request_rec are null
On Wed, Mar 6, 2013 at 4:21 PM, Nce Rt <nc...@yahoo.com> wrote:
>
>
> A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
> r->content_type, r->parsed_uri.scheme
r->content_type is not related to any request header -- it's the
response content type. It won't be set early, before a response is
generated.
Re: some key fields of request_rec are null
Posted by Eric Covener <co...@gmail.com>.
On Wed, Mar 6, 2013 at 4:21 PM, Nce Rt <nc...@yahoo.com> wrote:
>
>
> A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
> r->content_type, r->parsed_uri.scheme
r->content_type is not related to any request header -- it's the
response content type. It won't be set early, before a response is
generated.
Re: some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
A custom handler which is registered to run first(APR_HOOK_FIRST) has these fields null when processing http request:
r->content_type, r->parsed_uri.scheme wherer is a pointer to request_rec
the http request on the wire has the content_type header set.
r->parsed_uri.path is not null though.
apache is configured as reverse proxy here.
Re: some key fields of request_rec are null (corrected message)
Posted by Nce Rt <nc...@yahoo.com>.
A custom handler which is registered to run first(APR_HOOK_FIRST) has these fields null when processing http request:
r->content_type, r->parsed_uri.scheme
the http request on the wire has the content_type header set.
r->parsed_uri.path is not null though.
apache is configured as reverse proxy here.
some key fields of request_rec are null
Posted by Nce Rt <nc...@yahoo.com>.
A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request:
r->content_type, r->parsed_uri.scheme
the http request on the wire has the content_type header set.
r->parsed_uri.path is not null though.
apache is configured as reverse proxy here.
Re: how to send 401 code and custom entity from a hook
Posted by Daniel Gruno <ru...@cord.dk>.
On 03/06/2013 09:30 PM, Nce Rt wrote:
> I could send 401 status code from a custom apache module. But how to send a custom entity message in the http body? It seems to override any entity with a standard messaging to the client.
>
set r->status to 401, print your message and return OK
With regards,
Daniel.
how to send 401 code and custom entity from a hook
Posted by Nce Rt <nc...@yahoo.com>.
I could send 401 status code from a custom apache module. But how to send a custom entity message in the http body? It seems to override any entity with a standard messaging to the client.
Re: unknown 401 entity from apache
Posted by Nce Rt <nc...@yahoo.com>.
Are there other mailing lists from apache on Modules development?
________________________________
From: Nce Rt <nc...@yahoo.com>
To: "modules-dev@httpd.apache.org" <mo...@httpd.apache.org>
Sent: Monday, March 4, 2013 7:13 PM
Subject: unknown 401 entity from apache
Environment:
Platform- linux
Apache version- 2.2
Modules enabled- deflate dir autoindex env mime negotiation custom_module reqtimeout setenvif
Name of my module- custom_module which is positioned APR_HOOK_FIRST
As you can see, both auth and authz are disabled completely. httpd.conf and apache2.conf files reflect the same. In handling some proprietary authentication protocol in my custom_module, I do return 401 status code along with a custom entity which goes thro' fine to the client. But when I send a second 401 status return (required by my own auth protocol) along with a custom entity, client do get the 401 status but a different entity below which I don't send:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>401 Authorization Required</title></head><body><h1>Authorization Required</h1><p>This server could not verify that youare authorized to access the documentrequested. Either you supplied the wrongcredentials (e.g., bad password), or yourbrowser doesn't understand how to supplythe credentials required.</p></body></html>
The entity I put doesn't get sent out the client but the above. I've not defined any ErrorDocument directive with the above message. Any clues?
unknown 401 entity from apache
Posted by Nce Rt <nc...@yahoo.com>.
Environment:
Platform- linux
Apache version- 2.2
Modules enabled- deflate dir autoindex env mime negotiation custom_module reqtimeout setenvif
Name of my module- custom_module which is positioned APR_HOOK_FIRST
As you can see, both auth and authz are disabled completely. httpd.conf and apache2.conf files reflect the same. In handling some proprietary authentication protocol in my custom_module, I do return 401 status code along with a custom entity which goes thro' fine to the client. But when I send a second 401 status return (required by my own auth protocol) along with a custom entity, client do get the 401 status but a different entity below which I don't send:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>401 Authorization Required</title></head><body><h1>Authorization Required</h1><p>This server could not verify that youare authorized to access the documentrequested. Either you supplied the wrongcredentials (e.g., bad password), or yourbrowser doesn't understand how to supplythe credentials required.</p></body></html>
The entity I put doesn't get sent out the client but the above. I've not defined any ErrorDocument directive with the above message. Any clues?