cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Negative Matching Constructs && Mime Type Matching
Date Wed, 28 Nov 2001 14:00:23 GMT
Stefano Mazzocchi wrote:

> Berin Loritsch wrote:
>>While using Cocoon to generate the developer's docs, I have discovered some use
>>cases where a more flexible matcher should be considered.  First, let me outline
>>how it works (now that we can follow links....):


>><map:match pattern="api/**">
>><map:generate-error type="404"/>
>>The Aggregate matching would change the way patterns are expressed.  I know we have
>>a RegExp matcher--which is great, but sometimes we want something more familiar:
>><map:match pattern="{api|diagrams}/**">
>><map:generate-error type="404"/>
> Gosh, I had the *exact* same feeling that we need something in between
> star-matching and regexp-mathing.

That's my point.  In fact, it would be Really cool if this hybrid matcher was a wrapper
around the RegExp matcher, and merely did a translation on the pattern!

> I already proposed it and it got rejected, I'd be all for it!!!

No-one said we can't implement a third matcher.  It would be worth investigating--then
we have the advantage of seeing which is most useful by natural selection (following
Darwinian theory, which doesn't always apply to every situation...).

What did you think about being able to *explicitly* raise an error from the sitemap?
Sometimes the implied error thing is a pain to deal with.  This is especially true if you
want fine control over your URI space and it is either impossible to exclude a range using
RegExp, or the resulting match pattern is too complex for any mortal to understand.

The errors I would explicitly like to raise are the 400 series errors:

400  Bad Request
401  Unauthorized
402  Payment Required
403  Forbidden
404  Not Found
405  Method Not Allowed (Although I am not sure that I know how to enforce this at the
                          sitemap level).
406  Not Acceptable  (I have to examine what this is for again--I am going through the
                       HTTP spec contents...)
407  Proxy Authentication Required
408  Request Timeout
409  Conflict
410  Gone
411  Length Required (disallow chunking on SOAP requests or uploads....)
412  Precondition Failed
413  Request Entity Too Large
414  Request URI Too Long
415  Unsupported Media Type
416  Request Range Not Satisfiable
417  Expectation Failed

And possible the 500 series errors:

500  Internal Server Error

501  Not Implemented
502  Bad Gateway
503  Service Unavailable
504  Gateway Timeout
505  HTTP Version Not Supported

>>This also opens the door for something equally powerful on the positive matching side:
>><map:match pattern="**/images/*.{gif|jpg|png}">
>><map:select type="parameter">
>><map:parameter name="parameter" value="{3}"/>
>><map:when test="jpg">
>><map:read src="images/{2}.{3}" mime-type="image/jpeg"/>
>><map:read src="images/{2}.{3}" mime-type="image/{3}"/>
> or even
>  <map:match patter="**/images/*.{gif|jpeg|png}">
>   <map:read src="images/{2}.{3}" mime-type="image/{3}"/>
>  </map:match>
> since nobody forces you to use three-letters extensions for your URIs :)

True--though it is a common convention.

Note: Giacomo mentioned that the Readers and Serializers are supposed to rely
       on the environment's Mime Mapping to handle the cases where it is not
       declared either in the component section or the pipeline section.

>>Of course, then I would want to go a step further and explicitly state my mime-type
>>first in the select statement and only have one read.
>><map:mime-type value="image/jpeg"/>
>>Although, we can apply separation of concerns again.  In other words, mime-type matching
>>is not always a concern of the sitemap.  URIs with standard extensions should not
>>to have the mime-type matched by the sitemap.  IOW, standard extensions such as ".pdf",
>>".jpg", ".gif", ".png", ".rtf", etc. should have a table that automatically gets looked
>>up and applied to the response.  This can be be a mimetypes file that can either be
>>simple properties file (there are only a flat hierarchy to mime-type resolution) or
>>simplified configuration file:
>><mime:entry extension="pdf" type="application/pdf"/>
>>Of course It can be grouped for maintenance purposes like this:
>><mime:table group="application">
>><mime:entry extension="pdf" type="pdf"/>
>><mime:table group="image">
>><mime:entry extension="jpg" type="jpeg"/>
>><mime:entry extension="gif" type="gif"/>
>>The table approach can be further shortened by removing the "type" attribute if it
is the
>>same as the extension.  Keep in mind that command line environments and other yet-to-be
>>created environments won't have the same mechanisms for mime-type resolution, and
it should
>>be easy to create a general component that performs the resolution for you.  This
way 90%
>>of all mime-type declarations can be resolved in a maintainable and uniform manner.
>>The only need for the mime-type would be when your URI does not have an extension,
or it is
> I thought this was already implemented? isn't it?

This is only implemented for the servlet environment.  There is no way to have a standard
of mime-mappings independently of the environment.  IOW, the Servlet environment has it's
the CLI environment has another way (or ignores it), a Block embedded Cocoon would have yet
another way.

Do you see the conundrum?


"Those who would trade liberty for
  temporary security deserve neither"
                 - Benjamin Franklin

To unsubscribe, e-mail:
For additional commands, email:

View raw message