re: CVS commit: src/libexec/httpd

[Christos Zoulas]

On Dec 19,  1:34pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/libexec/httpd

| i don't think it matters where the failure happens.  we only need
| one frontend function, and it can exit as necessary.  you can tell
| from the contents of struct bozohttpd_t whether a reply can be sent
| upon error, or simply exiting.

Ok, how can I tell?

| (it seems that i let strdup(3) back in when i merged agc's library
| code, i should have caught that then.   oh well.)

No problem, I fixed most of them.

| the failure should always log -- but a reply depends.

Right.

christos

Re: CVS commit: src/libexec/httpd

[Christos Zoulas]

In article <20871.1450494...@splode.eterna.com.au>,
matthew green   wrote:
>Christos Zoulas writes:
>> On Dec 19,  1:34pm, m...@eterna.com.au (matthew green) wrote:
>> -- Subject: re: CVS commit: src/libexec/httpd
>> 
>> | i don't think it matters where the failure happens.  we only need
>> | one frontend function, and it can exit as necessary.  you can tell
>> | from the contents of struct bozohttpd_t whether a reply can be sent
>> | upon error, or simply exiting.
>> 
>> Ok, how can I tell?
>
>looks like after this:
>
>   request->hr_file = file;
>
>which means checking httpd->request && httpd->request->hr_file
>would be sufficient.

Well, bozo_http_error() check those two and also writes to stdout
if those are not set.
I was looking for something that would skip the Content-type etc.

christos

re: CVS commit: src/share/mk

[Christos Zoulas]

On Dec 19,  1:26pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/share/mk

| thanks for writing sortinfo!
| 
| can you apply this all the time?  i find it really frustrating
| when the top level file is unsorted and irregular.
| 

It is applied all the time now...

christos

re: CVS commit: src/share/mk

[matthew green]

"Christos Zoulas" writes:
> Module Name:  src
> Committed By: christos
> Date: Fri Dec 18 18:57:56 UTC 2015
> 
> Modified Files:
>   src/share/mk: bsd.info.mk bsd.own.mk
> 
> Log Message:
> Sort texinfo dir file for MKREPRO

thanks for writing sortinfo!

can you apply this all the time?  i find it really frustrating
when the top level file is unsorted and irregular.

thanks.


.mrg.

re: CVS commit: src/libexec/httpd

[matthew green]

> >the whole point of having bozofunc() is to avoid having to do any
> >error checking in it.  but now there are calls to several of these
> >that do check errors, and plus the names are too similar.
> >
> >there shouldn't really be a distinction.  all the calls to strdup()
> >you adjusted are (newish) bugs that should just have called
> >bozostrdup(), and there should be no bozo_strdup().  looks like the
> >vast majority of the strdup() calls were added when i merged
> >libbozo work, 5.5 years ago, plus a single one from the initial
> >import.
> 
> I think that there are strdup/alloc/ calls that happen before connection
> time and ones that happen before during configuration and setup. We can
> either have two functions to handle failure appropriately, or one (which
> I prefer I think) and that checks the http->logstate or something to see if
> it should log, or send a response, or both. This requires a bit more
> surgery... Yes, having two functions with similar names is nasty and silly
> and I am not planning to keep it. I just wanted to have some discussion
> first on what to do to solve it. There are 2 or so more strdups that are
> unchecked in the prefs. Let me know how you prefer to go and I will fix
> them.

i don't think it matters where the failure happens.  we only need
one frontend function, and it can exit as necessary.  you can tell
from the contents of struct bozohttpd_t whether a reply can be sent
upon error, or simply exiting.

(it seems that i let strdup(3) back in when i merged agc's library
code, i should have caught that then.   oh well.)

the failure should always log -- but a reply depends.

thanks.


.mrg.

re: CVS commit: src/libexec/httpd

[matthew green]

Christos Zoulas writes:
> On Dec 19,  1:34pm, m...@eterna.com.au (matthew green) wrote:
> -- Subject: re: CVS commit: src/libexec/httpd
> 
> | i don't think it matters where the failure happens.  we only need
> | one frontend function, and it can exit as necessary.  you can tell
> | from the contents of struct bozohttpd_t whether a reply can be sent
> | upon error, or simply exiting.
> 
> Ok, how can I tell?

looks like after this:

request->hr_file = file;

which means checking httpd->request && httpd->request->hr_file
would be sufficient.


.mrg.