cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Date Wed, 05 Nov 2003 13:57:41 GMT
 

> 
> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org] 
> Sent: woensdag 5 november 2003 14:29
> To: dev@cocoon.apache.org
> 
> Unico Hommes wrote:
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: Gianugo Rabellino [mailto:gianugo@apache.org]
> >>Sent: woensdag 5 november 2003 14:02
> >>To: dev@cocoon.apache.org
> >>
> >>Stefano Mazzocchi wrote:
> >>
> >>
> >>>>setStatus' friends the sendError brothers are also be 
> eligible for 
> >>>>FOM membership. But this change has a dependency on the 
> discussion 
> >>>>about bodyless responses since if you'd do a sendError 
> from a flow 
> >>>>script and then send a page afterwards this would result 
> in errors.
> >>>
> >>>
> >>>I dislikde "sendError" because, in fact, HTTP does not have the 
> >>>concept of errors, but only status codes and empty-payload
> >>
> >>responses.
> >>
> >>>In the future, it's entirely possible to have a 309 or
> >>
> >>equivalent that
> >>
> >>>is not an error, but has a empty-payload response. I would
> >>
> >>dislike to
> >>
> >>>call "sendError()" to send something that is not an error,
> >>
> >>feels hacky.
> >>
> >>>I think the optimal solution is:
> >>>
> >>> 1) add response.setStatus() in FOM
> >>> 2) allow the flowscript to terminate without calling
> >>
> >>sendPage* [thus
> >>
> >>>resulting in an empty payload]
> >>
> >>Sorry to jump in late, I'm probably lagging behind a few posts, but 
> >>was the possibility of having *pipelines* send empty payload 
> >>considered instead? This way flow will always have to 
> sendPage(), but 
> >>the result would be empty content anyway. With the added bonus of 
> >>having the pipeline flexibility to, say, set headers.
> >>
> > 
> > 
> > But the function of a pipeline is specifically towards the 
> production of
> > an xml response body. To have to set up all the components, 
> execute the
> > pipeline and then fooling the pipeline to send its data to 
> a null output
> > or refrain from pipeline execution altogether? In some 
> scenarios that
> > may be necessary, for instance in the case of the http HEAD 
> function.
> > The point is, you shouldn't have to, because there are a lot of
> > situations where its just unneccesary overhead. (for example all the
> > dummy responses in the davmap sitemap)
> 
> I sure can see some use of this. In a few cases (think PUT) you might 
> have XML input flowing through the pipeline (say you might want to 
> transform it) yet you have to send an empty response: in this 
> scenario 
> using a pipeline looks like the best option to me. 

Hmm, not to me. The way I have implemented PUT in the current davmap
differs from what you are suggesting.

Here I use two pipelines. One generates the request body:

<map:pipeline internal-only="true">
  <map:match pattern="request/PUT">
    <map:generate type="stream" />
    <!-- <map:transform type="myfilter" /> -->
    <map:serialize type="xml" />
  </map:match>
</map:pipeline>

<map:pipeline>
  <map:match pattern="PUT/**">
    <map:call function="put">
      <map:parameter name="input" value="cocoon:/request/PUT" />
      <map:parameter name="output" value="{global:staging}{1}" />
    </map:call>
  </map:match>
</map:pipeline>

The flow uses essentially the internal only request body generating
pipeline in a processPipelineTo type of construct:

Function put(in,out) {
  
  var s1 = resolver.resolve(in);
  var s2 = resolver.resolve(out);
  cocoon.processPipelineTo(in.inputStream, out.ouputStream);
  
  cocoon.response.setStatus(201);
  
  // have to do:
  cocoon.sendPage("dummy",{});

  // but really want to do this:
  // return null;
}

> Also, I 
> feel that the 
> sitemap is core and flow, while being core, is somehow 
> "piggybacked" on 
> the sitemap. I tend to think, then, that deciding whether to 
> send output 
> or not should belong more to the sitemap than to the flow.
> 

The sitemap is always in control, we are talking about changing the
sitemap semantics in that a <map:call function /> is extended so that it
can signal the sitemap to terminate processing the request. Maybe we
could add an attribute specifically allowing the function to not send a
page such as in <map:call function="blah" redirect="false" /> but I
think this will only complicate things because now what happens if the
function does do a redirect? And what if we want to do what Vadim
suggested:

<map:call function="login">
  <map:generate />
  <map:transform />
  <map:serialize />
</map:call>

Function login() {
  while(!loggedIn) {
    sendPageAndWait("login");
    loggedIn = ..
  }
  return {user:"user",message:"message"};
}

-- Unico

> Ciao,
> 
> -- 
> Gianugo Rabellino
> Pro-netics s.r.l. -  http://www.pro-netics.com
> Orixo, the XML business alliance - http://www.orixo.com
>      (Now blogging at: http://blogs.cocoondev.org/gianugo/)
> 
> 
> 

Mime
View raw message