Thanks for the quick response Rodney!
Im not sure how I overlooked those classes. I searched JavaSoft for
'escape', and 'query string' and did not find any mention of them.
It appears that the query string is automatically encoded (at least for
spaces). However, I imagin
For a forward, you just put in an encoded query string for the path:
For an action mapping, you can use the parameter property
and have the action check for the code there
String code = mapping.getParameter();
David Corbin wrote:
>
> I've got
Email. I didn't put my question there. Thanks! I have a query
string which has a parameter named as: file%name. So after URL encoding, it is
encoded as: file%25name. And I found it will break strus action class. It
gives me the following error: javax.servlet.jsp.JspExcepti
Hi,
I am really sorry for my previous Email. I didn't put my question there. Thanks!
I have a query string which has a parameter named as: file%name. So after URL encoding, it is encoded as: file%25name. And I found it will break strus action class. It gives me the following
>>Query string is valueA=aaa&valueB=
Thx for reply.. but this causing me can't retrieve the second parameter
(valueB)
servlet.log("value A "+ request.getParameter("valueA"));
servlet.log("value B " +request.getParameter("valueB"
gt;
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 2:56 PM
Subject: Re: Dynamic forwardings...
> For a forward, you just put in an encoded query string for the path:
>
> path="/do/item/Add?code=whatever"/>
>
> For an action mapping, y
a more interesting question is
> > whether the url rewriting format is standardized? I haven't been able
> to
> > confirm that http://blah.com;jsessionid=42789?qry=test&qry2=test2 is
> > standard.
> >
>
> The URL rewriting format is also standardized; in secti
: <[EMAIL PROTECTED]>
> Sent: Sunday, August 26, 2001 2:56 PM
> Subject: Re: Dynamic forwardings...
>
> > For a forward, you just put in an encoded query string for the path:
> >
> > > path="/do/item/Add?code=whatever"/>
This seems to work to build up a "done" parameter:
StringBuffer done = request.getRequestURL();
String query = request.getQueryString();
if (query != null)
{
done.append("?").append(query);
}
response.sendRedirect(re
; > David Corbin wrote:
> > >
> > > I'm definately talking about "forward", but my "whatever" value is
> dynamic.
> > > It's based on input (a parameter) into the action. I don't yet
> understand
> > > the best solution for tha
> result of URL rewriting. The syntax is "strange",
> > as you put it, because the session id is encoded
> > as a path parameter, and not part of the query
> > string. This is all explained in the Servlet spec.
>
> Is it possible to fix this behavior somehow?
t; value is
dynamic.
> > It's based on input (a parameter) into the action. I don't yet
understand
> > the best solution for that.
> >
> > - Original Message -
> > From: "Ted Husted" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED
look something up. In that case, the link tag can take one
> or
> > > > more dynamic parameters, based on the collection of beans used to
> write
> > > > it.
> > > >
> > > > In that case, the action usually gets the parameters
ts the parameters from the request,
> > > and uses them to look up whatever is required.
> > >
> > > David Corbin wrote:
> > > >
> > > > I'm definately talking about "forward", but my "whatever" value is
> > dynamic.
ce, to look something up. In that case,
> the link tag can take one
> or
> > > > more dynamic parameters, based on the
> collection of beans used to
> write
> > > > it.
> > > >
> > > > In that case, the action usually gets the
> parameters from th
ot; value is
dynamic.
> > It's based on input (a parameter) into the action. I don't yet
understand
> > the best solution for that.
> >
> > - Original Message -
> > From: "Ted Husted" <[EMAIL PROTECTED]>
> > To:
The HTTP/1.0 spec defines a URI as:
...
rel_path = [ path ] [ ";" params ] [ "?" query ]
...
The Servlet spec states:
The session id must be encoded as a path parameter in the URL string. The
name of the parameter must be jsessionid.
Quoting "Ruth, Brice" <[
uot;?" query ]
...
The Servlet spec states:
The session id must be encoded as a path parameter in the URL string. The
name of the parameter must be jsessionid.
Quoting "Ruth, Brice" <[EMAIL PROTECTED]>:
Saul Q Yuan wrote:
-Original Message-
From: Ruth, Brice [m
he
> > > specification for a MIME part, and they are separated by a boundary,
>which
> > > is a line containing a pattern defined in a header at the top of the
> > > request.
> > >
> > > Each MIME part consists of a sequence of MIME headers, follow
gt; > David Corbin wrote:
> > >
> > > I'm definately talking about "forward", but my
> "whatever" value is
> dynamic.
> > > It's based on input (a parameter) into the
> action. I don't yet
List
> Subject: Re: how to disable (or work around) jsessionid in
> html:img sources
>
>
> The HTTP/1.0 spec defines a URI as:
>
> ...
> rel_path = [ path ] [ ";" params ] [ "?" query ]
> ...
>
> The Servlet spec states:
>
> The
for all of your actions? I found that if you don't you
will have
> a problem. It's either all or nothing. If it's nothing your on your
own. At
> least that has been my experience.
>
Right now I am NOT encoding my links. However, if my assumptions are
correct...
Encodin
ders, followed by a blank
> line, followed by the data for that MIME part, known as the body. A MIME
> header takes the form "header-name: value" - for example, "Content-type:
> text/plain". The body is just a bunch of data that conforms to the
> statements made ab
for testing.
>
> >
> > I'm using Tomcat4.0-m5 for my testing. I don't know what you are
> using.
> >
>
> I am using Tomcat 3.2
>
> >
> > Are you using the for all of your links? And are you
> using
> > for all of your actions? I
t the top of the
> > request.
> >
> > Each MIME part consists of a sequence of MIME headers, followed by a
blank
> > line, followed by the data for that MIME part, known as the body. A MIME
> > header takes the form "header-name: value" - for exampl
n a header at the top of the
> > request.
> >
> > Each MIME part consists of a sequence of MIME headers, followed by a
blank
> > line, followed by the data for that MIME part, known as the body. A MIME
> > header takes the form "header-name: value" - for examp
> MIME part. The fields in a multipart/form-data request each conform to
>the
> > > specification for a MIME part, and they are separated by a boundary,
>which
> > > is a line containing a pattern defined in a header at the top of the
> > > request.
> >
rsing of
a
> > > MIME part. The fields in a multipart/form-data request each conform to
> the
> > > specification for a MIME part, and they are separated by a boundary,
> which
> > > is a line containing a pattern defined in a header at the top of the
> > > reques
ar requests.
> > > >
> > > > What you are seeing in the packages you've looked at is the parsing
of
> a
> > > > MIME part. The fields in a multipart/form-data request each conform
to
> > the
> > > > specification for
st a bunch of data that conforms to the
statements made about it in the headers.
Every field in a multipart request is encoded this way. So where a regular
query using GET might contain a query string like this:
...&author=Martin&...
a multipart request would represent the same quer
30 matches
Mail list logo
