[jira] [Commented] (TS-1062) TSFetchUrl doesn't handle chunked encoding
[
https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177909#comment-13177909
]
James Peach commented on TS-1062:
-
This is another instance of events failing to be delivered correctly. The Http
SM layer knows that it's the end on the read, but ends up delivering
TS_EVENT_VCONN_READ_READY instead of TS_EVENT_VCONN_READ_COMPLETE.
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http) [0] State
Transition: ORIGIN_SERVER_OPEN -> SERVER_READ
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0] adding
producer 'http server'
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0] adding
consumer 'user agent'
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http) [0]
perform_cache_write_action CACHE_DO_NO_ACTION
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) tunnel_run
started, p_arg is NULL
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_cs)
tcp_init_cwnd_set 0
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_cs) desired TCP
congestion window is 0
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel)
[producer_run] do_dechunking p->chunked_handler.chunked_reader->read_avail() =
3144
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel)
[producer_run] do_dechunking p->chunked_handler.skip_bytes = 242
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler_chunked [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_chunk) read chunk
size of 20477 bytes
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_chunk) read 2896
bytes of an 20477 chunk
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_redirect)
[HttpTunnel::producer_handler] enable_redirection: [1 0 0] event: 100
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [fetch_handler]
calling fetch_plugin
[Dec 30 23:31:05.605] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_read] I am here read
[Dec 30 23:31:05.606] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_read] number of bytes in read ready 3144
[Dec 30 23:31:05.606] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler_chunked [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_chunk) read 1448
bytes of an 20477 chunk
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_redirect)
[HttpTunnel::producer_handler] enable_redirection: [1 0 0] event: 100
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler_chunked [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.676] Server {0x7fff7b5f9960} DEBUG: (http_chunk) read 1448
bytes of an 20477 chunk
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_redirect)
[HttpTunnel::producer_handler] enable_redirection: [1 0 0] event: 100
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [fetch_handler]
calling fetch_plugin
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_read] I am here read
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_read] number of bytes in read ready 2896
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
producer_handler_chunked [http server VC_EVENT_READ_READY]
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_chunk) read 1448
bytes of an 20477 chunk
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_redirect)
[HttpTunnel::producer_handler] enable_redirection: [1 0 0] event: 100
[Dec 30 23:31:05.677] Server {0x7fff7b5f9960} DEBUG: (http_tunnel) [0]
consumer_handler [user agent VC_EVENT_WRITE_R
[jira] [Assigned] (TS-1052) trafficserver restart does not work (needs to let old process die)
[ https://issues.apache.org/jira/browse/TS-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1052: - Assignee: Leif Hedstrom > trafficserver restart does not work (needs to let old process die) > -- > > Key: TS-1052 > URL: https://issues.apache.org/jira/browse/TS-1052 > Project: Traffic Server > Issue Type: Bug > Components: Management >Affects Versions: 3.1.2 > Environment: Ubuntu 11.10 64bit >Reporter: Billy Vierra >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.2 > > Attachments: trafficserver.diff > > > 'bin/trafficserver restart' does not wait for the old process to stop thus > causing the restart to fail. > In my testing this takes from 5-8sec to happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1057) Expose internal Base64 Encoding / Decoding
[ https://issues.apache.org/jira/browse/TS-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177861#comment-13177861 ] Igor Galić commented on TS-1057: We're hacking on a highly threaded, event based server - any APIs that are not compatible with this concept need to be addressed. > Expose internal Base64 Encoding / Decoding > -- > > Key: TS-1057 > URL: https://issues.apache.org/jira/browse/TS-1057 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.1.1 >Reporter: Yakov Kopel >Assignee: Leif Hedstrom >Priority: Minor > Labels: patch > Fix For: 3.1.2 > > Attachments: patch.diff > > Original Estimate: 24h > Remaining Estimate: 24h > > Expose internal Base64 Encoding / Decoding for using in the plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1057) Expose internal Base64 Encoding / Decoding
[ https://issues.apache.org/jira/browse/TS-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177808#comment-13177808 ] Leif Hedstrom commented on TS-1057: --- I'm looking at this, and I'm wondering if we should only use (and support) Base64 encode/decoding into a provided buffer? That avoids the ats_malloc() that gets called. Also, the ink_base64_decode() used for the decode is not reentrant (this is real bad!). So my suggestions is that we'll have to clean up all the ink_base64() code, and add appropriate API for the encoding part. We'll only support encoding / decoding into provided buffers, and all will be reentrant. I've started this, but realized there was a significant amount of legacy code, and changes to make, so wanted to ask if this seems like a reasonable way to go? The change would then be for the APIs to be e.g. tsapi size_t TSBase64Decode(const char *src, size length, unsigned char *dst, size_t dst_size); Thoughts? > Expose internal Base64 Encoding / Decoding > -- > > Key: TS-1057 > URL: https://issues.apache.org/jira/browse/TS-1057 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.1.1 >Reporter: Yakov Kopel >Assignee: Leif Hedstrom >Priority: Minor > Labels: patch > Fix For: 3.1.2 > > Attachments: patch.diff > > Original Estimate: 24h > Remaining Estimate: 24h > > Expose internal Base64 Encoding / Decoding for using in the plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1057) Expose internal Base64 Encoding / Decoding
[ https://issues.apache.org/jira/browse/TS-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1057: - Assignee: Leif Hedstrom > Expose internal Base64 Encoding / Decoding > -- > > Key: TS-1057 > URL: https://issues.apache.org/jira/browse/TS-1057 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.1.1 >Reporter: Yakov Kopel >Assignee: Leif Hedstrom >Priority: Minor > Labels: patch > Fix For: 3.1.2 > > Attachments: patch.diff > > Original Estimate: 24h > Remaining Estimate: 24h > > Expose internal Base64 Encoding / Decoding for using in the plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1014) slow log can not print logs well on 32-bit system, I changed the %d to RPI64
[ https://issues.apache.org/jira/browse/TS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1014: - Assignee: Leif Hedstrom > slow log can not print logs well on 32-bit system, I changed the %d to RPI64 > > > Key: TS-1014 > URL: https://issues.apache.org/jira/browse/TS-1014 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.1.0 > Environment: 32-bit system >Reporter: weijin >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.2 > > Attachments: slow_log.diff > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-841) Refactor SSL code to make it possible to perform NPN negotiation without entering the HTTP SM
[ https://issues.apache.org/jira/browse/TS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177764#comment-13177764 ] James Peach commented on TS-841: >From IRC discussion: 6:17pm] zwoop: but, not sure it should be named TSNetAcceptTLS() [6:17pm] zwoop: because, TSNetAccept() implies that you (the plugin) own the port [6:17pm] zwoop: but, with NPN, you "share" it [6:17pm] jpeach: that's an interesting point [6:17pm] zwoop: I think we'd wants something like TSRegisterNPNHandler(contp, npn_string); [6:17pm] zwoop: or some such [6:18pm] zwoop: where contp implements the SPDY statemachine (or whatever protocol it is) [6:18pm] jpeach: NPN implies an implementation where the server is able to route external ports to internal named endpoints [6:18pm] zwoop: and, it follows the same semantics as the continuation that you would normally provide with for TSNetAccept ... [6:29pm] jpeach: so NPN needs to be in core code [6:29pm] jpeach: we need an internal endpoint mapper to route NPN endpoints [6:29pm] jpeach: we need plugin API to hook it all up > Refactor SSL code to make it possible to perform NPN negotiation without > entering the HTTP SM > - > > Key: TS-841 > URL: https://issues.apache.org/jira/browse/TS-841 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, SSL >Reporter: Leif Hedstrom > Fix For: 3.1.3 > > > In order to make it possible to write protocol handlers like SPDY, we need to > negotiate NPN protocol before entering the HTTP SM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-777) Increasing logbuffer size makes us "drop" log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-777: Assignee: (was: Leif Hedstrom) > Increasing logbuffer size makes us "drop" log entries > - > > Key: TS-777 > URL: https://issues.apache.org/jira/browse/TS-777 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.1.8 >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB > makes us start losing log entries. This is bad, since increasing this setting > could be a way to increase performance for busy systems. I've for now set the > defaults to 16KB, which seems to be stable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1067) Remove unused config (and code) for bandwidth management
Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-999) Deprecate TSUrlDestroy ?
[ https://issues.apache.org/jira/browse/TS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-999. -- Resolution: Fixed > Deprecate TSUrlDestroy ? > > > Key: TS-999 > URL: https://issues.apache.org/jira/browse/TS-999 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.2 > > > This API is a complete no-op as of quite a while ago. Should we just > deprecate it? Or, does anyone foresee a future where we actually need to call > TSUrlDestroy? Alan? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-999) Deprecate TSUrlDestroy ?
[ https://issues.apache.org/jira/browse/TS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-999: - Fix Version/s: (was: 3.1.3) 3.1.2 > Deprecate TSUrlDestroy ? > > > Key: TS-999 > URL: https://issues.apache.org/jira/browse/TS-999 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.2 > > > This API is a complete no-op as of quite a while ago. Should we just > deprecate it? Or, does anyone foresee a future where we actually need to call > TSUrlDestroy? Alan? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1048) Add TS API to enable plugins to use traffic server configuration infrastructure
[ https://issues.apache.org/jira/browse/TS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177712#comment-13177712 ] Leif Hedstrom commented on TS-1048: --- Bianca: Is the diff.txt patch the final version you want us to review and commit ? Thanks, -- leif > Add TS API to enable plugins to use traffic server configuration > infrastructure > > > Key: TS-1048 > URL: https://issues.apache.org/jira/browse/TS-1048 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, TS API > Environment: Centos 6 >Reporter: bianca cooper >Assignee: Leif Hedstrom >Priority: Minor > Labels: api-addition, configuration > Fix For: 3.1.2 > > Attachments: diff.txt > > Original Estimate: 72h > Remaining Estimate: 72h > > Export RecRegisterConfigInt and RecRegisterConfigString to enable adding a > configuration record to the records hashtable. > Once plugin new configuration records should be added, the addition will be > done by calling the API in the plugin code. No need to add the record to > RecordsConfig static array. No need to recompile the ATS each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-312) add option to always share keep-alive connections to the origin server
[ https://issues.apache.org/jira/browse/TS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-312: Assignee: (was: Leif Hedstrom) > add option to always share keep-alive connections to the origin server > --- > > Key: TS-312 > URL: https://issues.apache.org/jira/browse/TS-312 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.3.0 > > > (was yahoo bug 1411758) > Original description > by Bryan Call (bcall) 2 years ago at 2007-08-08 13:35 > Leif and I were talking about extending the meaning of > proxy.config.http.share_server_session for reusing keep-alive connections > from the TS server and the origin server, for separate clients attached to > TS. You can read more about this in > [BUG 1162233]. The configuration options should be: > so lets add more "options" to share_server_session? E.g. > 0 - Never share/reuse connections > 1 - Share/reuse connections if max_connections is set (default) > 2 - Always try to share-reuse connections > option 1 will give the behavior we currently have and 2 will always try to > share the keep-alive connections to the > origin servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[
https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-254.
--
Resolution: Fixed
Resolving for now, please reopen if there is a problem with this proposal.
> Add TSEscapifyString() and TSUnescapifyString()
>
>
> Key: TS-254
> URL: https://issues.apache.org/jira/browse/TS-254
> Project: Traffic Server
> Issue Type: New Feature
> Components: TS API
>Affects Versions: 3.0.0
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 3.1.2
>
>
> It would be very convenient for plugin developers to have SDK APIs that
> allows for escaping and unescaping of strings. E.g.
> TSEscapifyString("http://www.ogre.com/ogre.png";)
> -> http%3A%2F%2Fwww.ogre.com%2Fogre.png
> TSUnescapifyString("http%3A%2F%2Fwww.ogre.com%2Fogre.png)
> -> http://www.ogre.com/ogre.png
> The "unescapify" string is fairly straight forward, but the "escapify"
> version might benefit from taking an (optional) table which describes what
> characters needs to be escaped (e.g. in in some cases you want a / to be
> escaped, but in others you do not).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
