|
Issue with Nokia HttpConnection.flush()
Hello everybody, I've been trying to implement a client-server application that exchanges byte arrays through a HTTP connection. My client-server application works fine with a Motorola V3, but when I try to connect from a Nokia 5310 XpressMusic, the input stream in the server cannot be read (it comes empty). I used a software that receives the connection and forwards the request to the server, to see some information about what was being sent by the clients, so I got the information below:
In the successful Motorola version, the header parameters are: content-length: -1 (although I explicitly set it to the byte array length) connection: close (implicitly set) content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set) and the actual data sent has the chunked formatting (the chunk size prepended and a zeroed chunk size to inform the end of the chunks sequence), as below: 29 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
0 In the other hand, the unsuccessful Nokia version has the following header parameters: content-length: <the actual data length> (explicitly set) connection: keep alive (implicitly set) content-type: application/x-www-form-urlencoded (explicitly set)
<no transfer-encoding parameter set> and the actual data sent does not have the chunked formating, as below: 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š› I used pretty much the networking implementation as defined in the API. In addition, as far as I could understand, the call to HttpConnection.flush() sets the transfer-encoding header parameter to chunked, but it only works for the Motorola version. Without it, none of the two versions works fine, as it seems that the server can only deal with chunked data.
I've tried to find something in the Forum Nokia, KVM-Interests archives and Google, but without actual success. If you guys have any idea on how to work this around, either in the client application or in the server application, I'd appreciate.
Many thanks. Best regards, Ricardo Scholz. -- ricardo]scholz meantime]mobile.creations +55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: Issue with Nokia HttpConnection.flush()
Some parts of this message have been removed.
Learn more about Nabble's security policy.
content-length: -1 (although I explicitly set it to the byte array
length)
connection: close (implicitly set)
content-type:
application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked
(implicitly set)
you cant have a chunked with a content length! it's
one or the other.
----- Original Message -----
Sent: Monday, June 22, 2009 9:25 PM
Subject: Issue with Nokia
HttpConnection.flush()
Hello everybody,
I've been trying to implement a
client-server application that exchanges byte arrays through a HTTP
connection. My client-server application works fine with a Motorola V3, but
when I try to connect from a Nokia 5310 XpressMusic, the input stream in the
server cannot be read (it comes empty). I used a software that receives the
connection and forwards the request to the server, to see some information
about what was being sent by the clients, so I got the information
below:
In the successful Motorola version, the header parameters
are:
content-length: -1 (although I explicitly set it to the byte array
length)
connection: close (implicitly set)
content-type:
application/x-www-form-urlencoded (explicitly set)
transfer-encoding:
chunked (implicitly set)
and the actual data sent has the chunked
formatting (the chunk size prepended and a zeroed chunk size to inform the end
of the chunks sequence), as
below:
29
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
0
In
the other hand, the unsuccessful Nokia version has the following header
parameters:
content-length: <the actual data length> (explicitly
set)
connection: keep alive (implicitly set)
content-type:
application/x-www-form-urlencoded (explicitly set)
<no transfer-encoding
parameter set>
and the actual data sent does not have the chunked
formating, as
below:
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
I used
pretty much the networking implementation as defined in the API. In addition,
as far as I could understand, the call to HttpConnection.flush() sets the
transfer-encoding header parameter to chunked, but it only works for the
Motorola version. Without it, none of the two versions works fine, as it seems
that the server can only deal with chunked data.
I've tried to find
something in the Forum Nokia, KVM-Interests archives and Google, but without
actual success.
If you guys have any idea on how to work this around,
either in the client application or in the server application, I'd
appreciate.
Many thanks.
Best regards,
Ricardo
Scholz.
--
ricardo]scholz
meantime]mobile.creations
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the body of
the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: Issue with Nokia HttpConnection.flush()
Hi All, There's a mistake in the first message, when I said HttpConnection.flush() I meant OutputStream.flush(). Hi Chris, Thanx for your reply. Yes, you're right. Setting the content-length makes no sense if the chunked protocol prepends each chunk length at the beginning of the chunks. The Motorola version content-length is overwritten to -1, and works fine.
My question is: why the Nokia version does not overwrite the content-length property to -1 when I call OutputStream.flush() [what seems to be the method that makes transfer-encoding be changed to chunked in the Motorola version]? Also, this method does not make the transfer-encoding be changed to chunked, nor actually includes the prepended chunks length in the message body [it seems to infuence both in the Motorola version].
I can't underestand how to get control of 'chunking' turnning on/off. (I don't even know whether it is possible or not). I'll try without setting the content-length (as setting it is useless and makes no sense anyway ;)
Best regards, Ricardo. On Mon, Jun 22, 2009 at 11:21 PM, Chris B <kvm2@...> wrote:
content-length: -1 (although I explicitly set it to the byte array
length)
connection: close (implicitly set)
content-type:
application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked
(implicitly set)
you cant have a chunked with a content length! it's
one or the other.
----- Original Message -----
Sent: Monday, June 22, 2009 9:25 PM
Subject: Issue with Nokia
HttpConnection.flush()
Hello everybody, I've been trying to implement a
client-server application that exchanges byte arrays through a HTTP
connection. My client-server application works fine with a Motorola V3, but
when I try to connect from a Nokia 5310 XpressMusic, the input stream in the
server cannot be read (it comes empty). I used a software that receives the
connection and forwards the request to the server, to see some information
about what was being sent by the clients, so I got the information
below: In the successful Motorola version, the header parameters
are: content-length: -1 (although I explicitly set it to the byte array
length) connection: close (implicitly set) content-type:
application/x-www-form-urlencoded (explicitly set) transfer-encoding:
chunked (implicitly set) and the actual data sent has the chunked
formatting (the chunk size prepended and a zeroed chunk size to inform the end
of the chunks sequence), as
below: 29 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š› 0 In
the other hand, the unsuccessful Nokia version has the following header
parameters: content-length: <the actual data length> (explicitly
set) connection: keep alive (implicitly set) content-type:
application/x-www-form-urlencoded (explicitly set) <no transfer-encoding
parameter set> and the actual data sent does not have the chunked
formating, as
below: 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š› I used
pretty much the networking implementation as defined in the API. In addition,
as far as I could understand, the call to HttpConnection.flush() sets the
transfer-encoding header parameter to chunked, but it only works for the
Motorola version. Without it, none of the two versions works fine, as it seems
that the server can only deal with chunked data. I've tried to find
something in the Forum Nokia, KVM-Interests archives and Google, but without
actual success. If you guys have any idea on how to work this around,
either in the client application or in the server application, I'd
appreciate. Many thanks. Best regards, Ricardo
Scholz. --
ricardo]scholz meantime]mobile.creations +55[81]8664.8665
-- ricardo]scholz +55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: Issue with Nokia HttpConnection.flush()
Hi Ricardo,
no, You can't take influence on the transfer-encoding. Motorola uses
chunked, Nokia doesn't. So it's an absolute must to write the
content-length to the header for Nokia phones.
But why on earth do
you set the content-type? In my opinion you should leave it out unless
you really encode you data properly before streaming it.
flush() doesn't influence the transfer-encoding at all. It simply
empties the internal buffer. Besides flush ist called automatically,
when closing a connection.
Do you close the connection? If the header says "connection:
keep-alive", you have to do so. Otherwise the server ist waiting for
content until tomorrrow.
Best,
Roger
Ricardo Scholz schrieb:
Hi All,
There's a mistake in the first message, when I said
HttpConnection.flush() I meant OutputStream.flush().
Hi Chris,
Thanx for your reply. Yes, you're right. Setting the content-length
makes no sense if the chunked protocol prepends each chunk length at
the beginning of the chunks. The Motorola version content-length is
overwritten to -1, and works fine.
My question is: why the Nokia version does not overwrite the
content-length property to -1 when I call OutputStream.flush() [what
seems to be the method that makes transfer-encoding be changed to
chunked in the Motorola version]? Also, this method does not make the
transfer-encoding be changed to chunked, nor actually includes the
prepended chunks length in the message body [it seems to infuence both
in the Motorola version].
I can't underestand how to get control of 'chunking' turnning on/off.
(I don't even know whether it is possible or not).
I'll try without setting the content-length (as setting it is useless
and makes no sense anyway ;)
Best regards,
Ricardo.
On Mon, Jun 22, 2009 at 11:21 PM, Chris B <kvm2@...>
wrote:
content-length: -1 (although I explicitly set it to the byte
array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)
you cant have a chunked with a
content length! it's one or the other.
-----
Original Message -----
Sent:
Monday, June 22, 2009 9:25 PM
Subject:
Issue with Nokia HttpConnection.flush()
Hello everybody,
I've been trying to implement a client-server application that
exchanges byte arrays through a HTTP connection. My client-server
application works fine with a Motorola V3, but when I try to connect
from a Nokia 5310 XpressMusic, the input stream in the server cannot be
read (it comes empty). I used a software that receives the connection
and forwards the request to the server, to see some information about
what was being sent by the clients, so I got the information below:
In the successful Motorola version, the header parameters are:
content-length: -1 (although I explicitly set it to the byte array
length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)
and the actual data sent has the chunked formatting (the chunk size
prepended and a zeroed chunk size to inform the end of the chunks
sequence), as below:
29
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
0
In the other hand, the unsuccessful Nokia version has the following
header parameters:
content-length: <the actual data length> (explicitly set)
connection: keep alive (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
<no transfer-encoding parameter set>
and the actual data sent does not have the chunked formating, as below:
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
I used pretty much the networking implementation as defined in the API.
In addition, as far as I could understand, the call to
HttpConnection.flush() sets the transfer-encoding header parameter to
chunked, but it only works for the Motorola version. Without it, none
of the two versions works fine, as it seems that the server can only
deal with chunked data.
I've tried to find something in the Forum Nokia, KVM-Interests archives
and Google, but without actual success.
If you guys have any idea on how to work this around, either in the
client application or in the server application, I'd appreciate.
Many thanks.
Best regards,
Ricardo Scholz.
--
ricardo]scholz
meantime]mobile.creations
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@...
and include in the body of the message "signoff KVM-INTEREST". For
general help, send email to listserv@...
and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@...
and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of
the message "help".
--
ricardo]scholz
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the
body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
--
/**************************
* Roger F. Hösl
* ...
**************************/
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: Issue with Nokia HttpConnection.flush()
Hi all, it worked. Thank you all guys for your quick replies and attention. Roger, thanx for the information. It worked for both versions (Motorola and Nokia) by leaving the "content-type" out, seting the "content-length" properly and setting the "connection" property to "close".
Just for the records, in case
someone else has a similar problem:
no, You can't take influence on the transfer-encoding. Motorola uses
chunked, Nokia doesn't. So it's an absolute must to write the
content-length to the header for Nokia phones.
So, as far as I could understand, it's up to the kvm implementation
(for instance, manufacturers) to define the transfer-encoding when implementing
the HttpConnection. I have no control over it.
But why on earth do
you set the content-type? In my opinion you should leave it out unless
you really encode you data properly before streaming it.
I don't know why I set the content-type. During debug phase I've tried several approaches, and at some point, someone suggested me to set it to "application/x-www-urlencoded".
flush() doesn't influence the transfer-encoding at all. It simply
empties the internal buffer. Besides flush ist called automatically,
when closing a connection.
Yes, that's what I read from the docs. But when I took away the 'flush()' call in the Motorola version, the packages started being transfered in a non-chunked way. Maybe I had changed something else at the same time that I'm missing now, and then I misinterpreted the results.
Do you close the connection? If the header says "connection:
keep-alive", you have to do so. Otherwise the server ist waiting for
content until tomorrrow.
Now I set the "connection" parameter to close, and I close the OutputStream before calling HttpConnection.getResponseCode().
Thanx again.
Best regards,
Ricardo.
Ricardo Scholz schrieb:
Hi All,
There's a mistake in the first message, when I said
HttpConnection.flush() I meant OutputStream.flush().
Hi Chris,
Thanx for your reply. Yes, you're right. Setting the content-length
makes no sense if the chunked protocol prepends each chunk length at
the beginning of the chunks. The Motorola version content-length is
overwritten to -1, and works fine.
My question is: why the Nokia version does not overwrite the
content-length property to -1 when I call OutputStream.flush() [what
seems to be the method that makes transfer-encoding be changed to
chunked in the Motorola version]? Also, this method does not make the
transfer-encoding be changed to chunked, nor actually includes the
prepended chunks length in the message body [it seems to infuence both
in the Motorola version].
I can't underestand how to get control of 'chunking' turnning on/off.
(I don't even know whether it is possible or not).
I'll try without setting the content-length (as setting it is useless
and makes no sense anyway ;)
Best regards,
Ricardo.
On Mon, Jun 22, 2009 at 11:21 PM, Chris B <kvm2@...>
wrote:
content-length: -1 (although I explicitly set it to the byte
array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)
you cant have a chunked with a
content length! it's one or the other.
-----
Original Message -----
Sent:
Monday, June 22, 2009 9:25 PM
Subject:
Issue with Nokia HttpConnection.flush()
Hello everybody,
I've been trying to implement a client-server application that
exchanges byte arrays through a HTTP connection. My client-server
application works fine with a Motorola V3, but when I try to connect
from a Nokia 5310 XpressMusic, the input stream in the server cannot be
read (it comes empty). I used a software that receives the connection
and forwards the request to the server, to see some information about
what was being sent by the clients, so I got the information below:
In the successful Motorola version, the header parameters are:
content-length: -1 (although I explicitly set it to the byte array
length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)
and the actual data sent has the chunked formatting (the chunk size
prepended and a zeroed chunk size to inform the end of the chunks
sequence), as below:
29
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
0
In the other hand, the unsuccessful Nokia version has the following
header parameters:
content-length: <the actual data length> (explicitly set)
connection: keep alive (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
<no transfer-encoding parameter set>
and the actual data sent does not have the chunked formating, as below:
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
I used pretty much the networking implementation as defined in the API.
In addition, as far as I could understand, the call to
HttpConnection.flush() sets the transfer-encoding header parameter to
chunked, but it only works for the Motorola version. Without it, none
of the two versions works fine, as it seems that the server can only
deal with chunked data.
I've tried to find something in the Forum Nokia, KVM-Interests archives
and Google, but without actual success.
If you guys have any idea on how to work this around, either in the
client application or in the server application, I'd appreciate.
Many thanks.
Best regards,
Ricardo Scholz.
--
ricardo]scholz
meantime]mobile.creations
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@...
and include in the body of the message "signoff KVM-INTEREST". For
general help, send email to listserv@...
and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@...
and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of
the message "help".
--
ricardo]scholz
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the
body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
--
/**************************
* Roger F. Hösl
* ...
**************************/
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
-- ricardo]scholz +55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: Issue with Nokia HttpConnection.flush()
Some parts of this message have been removed.
Learn more about Nabble's security policy.
If in doubt write the headers and body
out manually with DataOutputStream.
----- Original Message -----
Sent: Tuesday, June 23, 2009 3:49
PM
Subject: Re: Issue with Nokia
HttpConnection.flush()
Hi all, it worked. Thank you all guys for your quick replies
and attention.
Roger, thanx for the information. It worked for both
versions (Motorola and Nokia) by leaving the "content-type" out, seting the
"content-length" properly and setting the "connection" property to
"close".
Just for the records, in case someone else has a similar
problem:
no,
You can't take influence on the transfer-encoding. Motorola uses chunked,
Nokia doesn't. So it's an absolute must to write the content-length to the
header for Nokia phones.
So, as far as I could understand, it's up to the kvm implementation
(for instance, manufacturers) to define the transfer-encoding when
implementing the HttpConnection. I have no control over it.
But why on earth
do you set the content-type? In my opinion you should leave it out unless
you really encode you data properly before streaming
it.
I don't know why I set the content-type. During debug phase I've
tried several approaches, and at some point, someone suggested me to set it to
"application/x-www-urlencoded".
flush() doesn't influence the transfer-encoding at all. It
simply empties the internal buffer. Besides flush ist called automatically,
when closing a connection.
Yes, that's what I read from the docs. But when I took away the
'flush()' call in the Motorola version, the packages started being transfered
in a non-chunked way. Maybe I had changed something else at the same time that
I'm missing now, and then I misinterpreted the results.
Do
you close the connection? If the header says "connection: keep-alive", you
have to do so. Otherwise the server ist waiting for content until
tomorrrow.
Now I set the "connection" parameter to close, and I close the
OutputStream before calling HttpConnection.getResponseCode().
Thanx
again.
Best regards,
Ricardo.
Ricardo Scholz schrieb:
Hi All,
There's a mistake in the first
message, when I said HttpConnection.flush() I meant
OutputStream.flush().
Hi Chris,
Thanx for your reply. Yes,
you're right. Setting the content-length makes no sense if the chunked
protocol prepends each chunk length at the beginning of the chunks. The
Motorola version content-length is overwritten to -1, and works fine.
My question is: why the Nokia version does not overwrite the
content-length property to -1 when I call OutputStream.flush() [what seems
to be the method that makes transfer-encoding be changed to chunked in the
Motorola version]? Also, this method does not make the transfer-encoding
be changed to chunked, nor actually includes the prepended chunks length
in the message body [it seems to infuence both in the Motorola
version].
I can't underestand how to get control of 'chunking'
turnning on/off. (I don't even know whether it is possible or
not).
I'll try without setting the content-length (as setting it is
useless and makes no sense anyway ;)
Best
regards,
Ricardo.
On Mon, Jun 22, 2009 at 11:21 PM, Chris B <kvm2@...> wrote:
content-length: -1 (although I explicitly set it to the byte array
length)
connection: close (implicitly set)
content-type:
application/x-www-form-urlencoded (explicitly set)
transfer-encoding:
chunked (implicitly set)
you cant have a chunked with a content
length! it's one or the other.
-----
Original Message -----
Sent:
Monday, June 22, 2009 9:25 PM
Subject:
Issue with Nokia HttpConnection.flush()
Hello everybody, I've been trying to implement a
client-server application that exchanges byte arrays through a HTTP
connection. My client-server application works fine with a Motorola
V3, but when I try to connect from a Nokia 5310 XpressMusic, the input
stream in the server cannot be read (it comes empty). I used a
software that receives the connection and forwards the request to the
server, to see some information about what was being sent by the
clients, so I got the information below: In the successful
Motorola version, the header parameters are: content-length: -1
(although I explicitly set it to the byte array length) connection:
close (implicitly set) content-type:
application/x-www-form-urlencoded (explicitly
set) transfer-encoding: chunked (implicitly set) and the
actual data sent has the chunked formatting (the chunk size prepended
and a zeroed chunk size to inform the end of the chunks sequence), as
below: 29 3333223
cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š› 0 In the other hand,
the unsuccessful Nokia version has the following header
parameters: content-length: <the actual data length>
(explicitly set) connection: keep alive (implicitly
set) content-type: application/x-www-form-urlencoded (explicitly
set) <no transfer-encoding parameter set> and the
actual data sent does not have the chunked formating, as
below: 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š› I
used pretty much the networking implementation as defined in the API.
In addition, as far as I could understand, the call to
HttpConnection.flush() sets the transfer-encoding header parameter to
chunked, but it only works for the Motorola version. Without it, none
of the two versions works fine, as it seems that the server can only
deal with chunked data. I've tried to find something in the
Forum Nokia, KVM-Interests archives and Google, but without actual
success. If you guys have any idea on how to work this around,
either in the client application or in the server application, I'd
appreciate. Many thanks. Best regards, Ricardo
Scholz. --
ricardo]scholz meantime]mobile.creations +55[81]8664.8665 ===========================================================================
To unsubscribe, send email to listserv@... and include in the body of the
message "signoff KVM-INTEREST". For general help, send email to listserv@... and include in the body of the
message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body of the
message "signoff KVM-INTEREST". For general help, send email to listserv@... and include in the body of the
message "help".
--
ricardo]scholz
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the body of the
message "signoff KVM-INTEREST". For general help, send email to listserv@... and include in the body of the
message "help". --
/**************************
* Roger F. Hösl
* ...
**************************/
===========================================================================
To unsubscribe, send email to listserv@... and include in the body of the
message "signoff KVM-INTEREST". For general help, send email to listserv@...
and include in the body of the message "help".
--
ricardo]scholz
+55[81]8664.8665
===========================================================================
To unsubscribe, send email to listserv@... and include in the body of
the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".
|
