You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Bryce Nesbitt <br...@obviously.com> on 2005/12/17 19:25:11 UTC

Content-Length HTTP headers and Velocimacro #macro definition

I'm a bit confused by this, and wonder if it is a reportable bug. 
There's not much strange in my configuration to explain it.  If my
velocity pages have a #macro definition in them, the HTTP header
Content-Length: is messed up. A very simple macro shows this. The
content length is 350 bytes, but only 249 bytes will be served:

-----------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

#macro( screwthingsupmacro $values )
    <p>I cause the Content-Length: header to be wrong!</p>
#end

<html>
<head>
    <title>Individual Member Application</title>
</head>
<body>
<form action="signup.action" method="POST"> This causes some clients to
work fine, others to blow chunks (that's a technical term :-).
</form>
</body>
</html>


-----------------------------------------------
host> wget --save-headers http://localhost:8080/exploded/signup/e_test.html

HTTP request sent, awaiting response... 200 OK
Length: 350 [text/html]
71% [=========================> ] 249 --.--K/s
ETA 00:02
Connection closed at byte 249. Retrying.

---------------------------------------
2005-12-17 09:42:43,049 - SimpleLog4JLogSystem initialized using logfile
'velocity.log'
2005-12-17 09:42:43,049 - SimpleLog4JLogSystem initialized using logfile
'velocity.log'
2005-12-17 09:42:43,049 -
**************************************************************
2005-12-17 09:42:43,049 -
**************************************************************
2005-12-17 09:42:43,050 - Starting Jakarta Velocity v1.3.1
2005-12-17 09:42:43,050 - Starting Jakarta Velocity v1.3.1


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org


Re: Content-Length HTTP headers and Velocimacro #macro definition

Posted by Bryce Nesbitt <br...@obviously.com>.
Nathan Bubna wrote:
>> Bryce wrote:
>> If my velocity pages have a #macro definition in them, the HTTP header
>> Content-Length: is messed up. A very simple macro shows this. The
>> content length is 350 bytes, but only 249 bytes will be served:
>
>
> ..if #macro definitions are causing that
> to be off, it is likely because the servlet or server that is setting
> that header is setting it according to the size of the *template* and
> not the size of the output generated by the template.
>
> so, could you tell us more about the servlet you are using?
Well, it's inherited code, but I'll try.
Yes, you're right that Content-Length: is exactly the size of the template.
The container is tomcat (4 or 5, does not matter)
With http://www.opensymphony.com XWork
This is all very deeply burried in a complex tangle of contributing
packages , so I don't necessarily know what plugs into what (sometimes
it feels like the knee bone is connected to the elbow bone).

Here is "velocity.properties":
--------------------------------------------------------------
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = 2
userdirective =
com.xxxxxxxxxx.denali.views.velocity.DashBoxDirective,com.xxxxxxxxxx.denali.views.velocity.SearchBoxDirective,com.xxxxxxxxxx.denali.views.velocity.ActionBoxDirective,com.xxxxxxxxxx.denali.views.velocity.TitleDirective,com.xxxxxxxxxx.denali.views.velocity.BoxDirective,com.xxxxxxxxxx.denali.views.velocity.ContentDirective
#@todo uncomment this for debugging information
#runtime.log.logsystem.class =
org.apache.velocity.runtime.log.SimpleLog4JLogSystem
#runtime.log.logsystem.log4j.category = chrome.velocity
directive.foreach.counter.initial.value = 0
velocimacro.library = WEB-INF/denali-macros.vm
-------------------------------------------------------------

Now that I realize Xwork, not just velocity, may be involved, I see a clue.

The pages in question end in ".html" and are referenced by direct URL. 
Turns out if I rename one file to ".vm", and start it in the odd way
that xwork starts pages:

    <package name="signup" extends="default" namespace="/signup">
        <action name="signup"
class="com.xxxxxxxxxx.denali.action.application.SignupAction">
            <result name="input" type="dynamic-velocity">
                <param name="prefix">signup/</param>
                <param name="input">_input</param>
                <param
name="location">/WEB-INF/views/signup/signup-input.vm</param>
            </result>
            <result name="success"
type="redirect">/signup/signup-success.html</result>
             ...

The content-length is OK.  So thanks to your help (really), I have a
solution. 

The only odd thing is that the other way worked at all... and was
deployed without anyone noticing the content-length issue.

       Bryce Nesbitt
       http://www.obviously.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org


Re: Content-Length HTTP headers and Velocimacro #macro definition

Posted by Nathan Bubna <nb...@gmail.com>.
a couple quick things.  Velocity 1.3.x is not the current release. 
Velocity 1.4 is and Velocity 1.5 hopefully will be soon.   i suppose
you are free to report bugs in that version, but don't expect us to
release a new 1.3.x version.  our efforts are focused elsewhere.

second, the Velocity template engine has nothing to do with setting
http headers.  in fact, even the deprecated VelocityServlet and its
successor the VelocityViewServlet do not set the content-length
header.   i have no idea what is setting that header for you.  perhaps
if you could tell us a bit more about your webapp configuration, that
might help us help you.  but i assure you that Velocity is not setting
the content-length header, and if #macro definitions are causing that
to be off, it is likely because the servlet or server that is setting
that header is setting it according to the size of the *template* and
not the size of the output generated by the template.

so, could you tell us more about the servlet you are using?

On 12/17/05, Bryce Nesbitt <br...@obviously.com> wrote:
> I'm a bit confused by this, and wonder if it is a reportable bug.
> There's not much strange in my configuration to explain it.  If my
> velocity pages have a #macro definition in them, the HTTP header
> Content-Length: is messed up. A very simple macro shows this. The
> content length is 350 bytes, but only 249 bytes will be served:
>
> -----------------------------------------------
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
>
> #macro( screwthingsupmacro $values )
>     <p>I cause the Content-Length: header to be wrong!</p>
> #end
>
> <html>
> <head>
>     <title>Individual Member Application</title>
> </head>
> <body>
> <form action="signup.action" method="POST"> This causes some clients to
> work fine, others to blow chunks (that's a technical term :-).
> </form>
> </body>
> </html>
>
>
> -----------------------------------------------
> host> wget --save-headers http://localhost:8080/exploded/signup/e_test.html
>
> HTTP request sent, awaiting response... 200 OK
> Length: 350 [text/html]
> 71% [=========================> ] 249 --.--K/s
> ETA 00:02
> Connection closed at byte 249. Retrying.
>
> ---------------------------------------
> 2005-12-17 09:42:43,049 - SimpleLog4JLogSystem initialized using logfile
> 'velocity.log'
> 2005-12-17 09:42:43,049 - SimpleLog4JLogSystem initialized using logfile
> 'velocity.log'
> 2005-12-17 09:42:43,049 -
> **************************************************************
> 2005-12-17 09:42:43,049 -
> **************************************************************
> 2005-12-17 09:42:43,050 - Starting Jakarta Velocity v1.3.1
> 2005-12-17 09:42:43,050 - Starting Jakarta Velocity v1.3.1
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org