Re: [MERGE] RFC-compliant object invalidation behaviour.

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 29 Aug 2008 13:05:30 +1200 (NZST)

> On tor, 2008-08-28 at 23:26 +1200, Amos Jeffries wrote:
>
>> > +const char *
>> > +urlAbsolute(const HttpRequest * req, const char *relUrl)
>> > +{
>> > + LOCAL_ARRAY(char, portbuf, 32);
>> > + LOCAL_ARRAY(char, urlbuf, MAX_URL);
>>
>> LOCAL_ARRAY is unfortunately not thread safe. Someone else may argue,
>> but I prefer to see them dead.
>
> I have always wanted to see them dead for many reasons.
>
> * On reasonable systems (i.e. most non-dos) the stack is a very suitable
> place for temporary allocations.
>
> * Using a static local array as return value will bite you from time to
> time even without threading, and is absolutely not thread safe..
>
>> > + char *path, *last_slash;
>> > +
>> > + if (relUrl == NULL) {
>> > + return (NULL);
>> > + }
>> > + if (req->method.id() == METHOD_CONNECT) {
>> > + return (NULL);
>> > + }
>> > + if (strchr(relUrl, ':') != NULL) {
>> > + return (NULL);
>>
>> Hmm, can relURL not contain the dynamic-part?
>> I'd expect those to have ':' sometimes.
>
> CONNECT URLs are a bit special.. but every other absolute URL must have
> a scheme:
>
> But relative URLs do not, ever..

I know that, what I was querying was relative URL such as:
  "/cgi-bin/parse.php?delim=:M"

Which are valid, and would barf on that test.
Only the " ", "/", ";", and "?" characters are required encoding by RFC 1738.

>
>
>> > + }
>> > + if (req->protocol == PROTO_URN) {
>> > + snprintf(urlbuf, MAX_URL, "urn:%s", req->urlpath.buf());
>>
>> ?? no hostname or anything but path on URNs?
>> Or is that a very badly named field?
>
> URNs is differnt from URLs.. more like news: where the URI identifies a
> resource as such and not where that something is located..
>
> urn:isbn:0-596-00162-2
>
> news:a.message_at_id
>

Thanks Henrik. Here I have been thinking they were semantically URL, with
only a differing host part.

>> Semantics of xstrdup() AFAIK already are that the recipient gets a
>> dynamic pointer and responsibility for its destruction.
>
> Yes. xstrdup() is the same as strdup() except that it never returns NULL
> and does not accept NULLs...
>
> Related to this xstrndup() is like strndup with the rules above plus
> that it always \0 terminates the result.
>
> Regards
> Henrik
>
Received on Fri Aug 29 2008 - 01:05:33 MDT

This archive was generated by hypermail 2.2.0 : Fri Aug 29 2008 - 12:00:06 MDT