You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Samisa Abeysinghe (JIRA)" <ji...@apache.org> on 2006/01/22 15:40:10 UTC
[jira] Created: (AXIS2C-23) HTTP transport does not seem to take
into account the content-lengh/chunk size
HTTP transport does not seem to take into account the content-lengh/chunk size
------------------------------------------------------------------------------
Key: AXIS2C-23
URL: http://issues.apache.org/jira/browse/AXIS2C-23
Project: Axis2-C
Type: Bug
Components: core/transport
Reporter: Samisa Abeysinghe
Priority: Critical
Fix For: M0.3
The read callback causes the server to hang at times when the parser tries to read more data when there are none.
Though this looks to be a problem with the SOAP builder, the callback is called from within libxml2, and hence the transport callback impl method should know how to tell the calling party that there are no more data. I used a timeout as a hack. But this solution need to be more clean with the transport looking for the end of the stream in line with the protocol in operation and letting the calling party know that there are no more data (that is return an empty buffer)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXIS2C-23) HTTP transport does not seem to take
into account the content-lengh/chunk size
Posted by "Sahan Gamage (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-23?page=all ]
Sahan Gamage closed AXIS2C-23:
------------------------------
Fix Version: Current (Nightly)
(was: M0.3)
Resolution: Fixed
Content length is checked for every HTTP POST, If it is not there a 411 (Lenght Required) is returned to the client. The content length is taken and stored in the callback context. Also the callback conntext contains the the char count read by the parser. If the char count exceeds the content length -1 is returned by the callback function to notify the parser about the end of data stream. At the moment we don't have chunking support. So the chunk size issue is not taken in to account at this moment.
> HTTP transport does not seem to take into account the content-lengh/chunk size
> ------------------------------------------------------------------------------
>
> Key: AXIS2C-23
> URL: http://issues.apache.org/jira/browse/AXIS2C-23
> Project: Axis2-C
> Type: Bug
> Components: core/transport
> Reporter: Samisa Abeysinghe
> Assignee: Sahan Gamage
> Priority: Critical
> Fix For: Current (Nightly)
>
> The read callback causes the server to hang at times when the parser tries to read more data when there are none.
> Though this looks to be a problem with the SOAP builder, the callback is called from within libxml2, and hence the transport callback impl method should know how to tell the calling party that there are no more data. I used a timeout as a hack. But this solution need to be more clean with the transport looking for the end of the stream in line with the protocol in operation and letting the calling party know that there are no more data (that is return an empty buffer)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS2C-23) HTTP transport does not seem to take
into account the content-lengh/chunk size
Posted by "Samisa Abeysinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-23?page=comments#action_12363570 ]
Samisa Abeysinghe commented on AXIS2C-23:
-----------------------------------------
Using a timeout is not the solution for the situation where it blocks on parser callback. Callback makes the server to appear *very slow*. This way we would be beaten by the Java implementation when it comes to speed. That is really bad :(
> HTTP transport does not seem to take into account the content-lengh/chunk size
> ------------------------------------------------------------------------------
>
> Key: AXIS2C-23
> URL: http://issues.apache.org/jira/browse/AXIS2C-23
> Project: Axis2-C
> Type: Bug
> Components: core/transport
> Reporter: Samisa Abeysinghe
> Priority: Critical
> Fix For: M0.3
>
> The read callback causes the server to hang at times when the parser tries to read more data when there are none.
> Though this looks to be a problem with the SOAP builder, the callback is called from within libxml2, and hence the transport callback impl method should know how to tell the calling party that there are no more data. I used a timeout as a hack. But this solution need to be more clean with the transport looking for the end of the stream in line with the protocol in operation and letting the calling party know that there are no more data (that is return an empty buffer)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AXIS2C-23) HTTP transport does not seem to take
into account the content-lengh/chunk size
Posted by "Sahan Gamage (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-23?page=all ]
Sahan Gamage reassigned AXIS2C-23:
----------------------------------
Assign To: Sahan Gamage
> HTTP transport does not seem to take into account the content-lengh/chunk size
> ------------------------------------------------------------------------------
>
> Key: AXIS2C-23
> URL: http://issues.apache.org/jira/browse/AXIS2C-23
> Project: Axis2-C
> Type: Bug
> Components: core/transport
> Reporter: Samisa Abeysinghe
> Assignee: Sahan Gamage
> Priority: Critical
> Fix For: M0.3
>
> The read callback causes the server to hang at times when the parser tries to read more data when there are none.
> Though this looks to be a problem with the SOAP builder, the callback is called from within libxml2, and hence the transport callback impl method should know how to tell the calling party that there are no more data. I used a timeout as a hack. But this solution need to be more clean with the transport looking for the end of the stream in line with the protocol in operation and letting the calling party know that there are no more data (that is return an empty buffer)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira