[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[
https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000683#comment-14000683
]
Ethan Lai commented on TS-2344:
---
The remap_redirect URL is used inside of build_error_response(), which set
correct Location header for building response body with %{Location}psh
field.
If this Location header is set after calling build_error_response(), response
body will have empty %{Location}psh field because it was already generated.
{code}
+ if ((status_code == HTTP_STATUS_TEMPORARY_REDIRECT ||
+ status_code == HTTP_STATUS_MOVED_TEMPORARILY ||
+ status_code == HTTP_STATUS_MOVED_PERMANENTLY)
+ s-remap_redirect) {
+s-hdr_info.client_response.value_set(MIME_FIELD_LOCATION,
MIME_LEN_LOCATION, s-remap_redirect, strlen(s-remap_redirect));
+ }
{code}
I'm not that familiar with passing additional parameter, remap_redirect_len
here, while calling build_error_response().
Please feel free to enhance this patch. :)
404 error was logged while url redirect request was processed corrctly
--
Key: TS-2344
URL: https://issues.apache.org/jira/browse/TS-2344
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Eddie
Assignee: Leif Hedstrom
Labels: Review
Fix For: 5.0.0
Attachments: no_redirect_after_map.patch
I am seeing a lot of entries in the error log for my url redirect request.
The request was processed correctly and I could see the expected response in
log as below:
2013-11-08 18:23:37 IP 301 FIN http://yahoo.com
http://www.yahoo.com/
But log messages like following were printed in the error log too, which
generates a lot of error logs (log rotation configured) and filling up disk
space pretty fast.
20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on
Accelerator) for 'http:///'
20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect)
for 'http:///'
I watched my tcpdump log and did not see that the 404 error was sent out at
all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in
the error log for my url redirect request. The request was processed correctly
I could see the expected response in log as well:
2013-11-08 18:23:37 IP 301 FIN http://yahoo.com
http://www.yahoo.com/
But log messages like following were printed too:
20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on
Accelerator) for 'http:///'
20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect)
for 'http:///'
I watched my tcpdump log and did not see that the 404 error was sent out at
all. I am using ATS/3.2.4 and following
is the log configuration.
CONFIG proxy.config.log.logging_enabled INT 3
CONFIG proxy.config.log.max_secs_per_buffer INT 1
CONFIG proxy.config.log.max_space_mb_for_logs INT 25000
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
CONFIG proxy.config.log.max_space_mb_headroom INT 1000
CONFIG proxy.config.log.hostname STRING localhost
CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver
CONFIG proxy.config.log.logfile_perm STRING rw-r--r--
CONFIG proxy.config.log.custom_logs_enabled INT 1
CONFIG proxy.config.log.squid_log_enabled INT 0
CONFIG proxy.config.log.squid_log_is_ascii INT 0
CONFIG proxy.config.log.squid_log_name STRING squid
CONFIG proxy.config.log.squid_log_header STRING NULL
CONFIG proxy.config.log.common_log_enabled INT 0
CONFIG proxy.config.log.common_log_is_ascii INT 1
CONFIG proxy.config.log.common_log_name STRING common
CONFIG proxy.config.log.common_log_header STRING NULL
CONFIG proxy.config.log.extended_log_enabled INT 0
CONFIG proxy.config.log.extended_log_is_ascii INT 0
CONFIG proxy.config.log.extended_log_name STRING extended
CONFIG proxy.config.log.extended_log_header STRING NULL
CONFIG proxy.config.log.extended2_log_enabled INT 0
CONFIG proxy.config.log.extended2_log_is_ascii INT 1
CONFIG proxy.config.log.extended2_log_name STRING extended2
CONFIG proxy.config.log.extended2_log_header STRING NULL
CONFIG proxy.config.log.separate_icp_logs INT 0
CONFIG proxy.config.log.separate_host_logs INT 0
Is this a bug or is this a misconfiguration? Does anyone have any idea?) and
following is the log configuration.
CONFIG proxy.config.log.logging_enabled INT 3
CONFIG proxy.config.log.max_secs_per_buffer INT 1
CONFIG proxy.config.log.max_space_mb_for_logs INT 25000
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
CONFIG proxy.config.log.max_space_mb_headroom INT 1000
CONFIG proxy.config.log.hostname STRING localhost
CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver
CONFIG proxy.config.log.logfile_perm STRING rw-r--r--
CONFIG
[jira] [Comment Edited] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[
https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000683#comment-14000683
]
Ethan Lai edited comment on TS-2344 at 5/17/14 5:56 AM:
The remap_redirect URL is used inside of build_error_response(), which set
correct Location header for building response body with %{Location}psh
field.
If this Location header is set after calling build_error_response(), response
body will have empty %{Location}psh field because it was already generated.
{code}
+ if ((status_code == HTTP_STATUS_TEMPORARY_REDIRECT ||
+ status_code == HTTP_STATUS_MOVED_TEMPORARILY ||
+ status_code == HTTP_STATUS_MOVED_PERMANENTLY)
+ s-remap_redirect) {
+s-hdr_info.client_response.value_set(MIME_FIELD_LOCATION,
MIME_LEN_LOCATION, s-remap_redirect, strlen(s-remap_redirect));
+ }
{code}
Current redirect_temporary response body (Please notice the empty Location):
{code}
HTTP/1.1 307 Redirect
Date: Sat, 17 May 2014 05:55:21 GMT
Server: ATS
Cache-Control: no-store
Content-Type: text/html; charset=utf-8
Content-Language: en
Connection: close
Location: https://www.example.com/
Content-Length: 283
HTML
HEAD
TITLEDocument Has Moved/TITLE
/HEAD
BODY BGCOLOR=white FGCOLOR=black
H1Document Has Moved/H1
HR
FONT FACE=Helvetica,ArialB
Description: The document you requested has moved to a new location. The new
location is -.
/B/FONT
HR
/BODY
{code}
I'm not that familiar with passing additional parameter, remap_redirect_len
here, while calling build_error_response().
Please feel free to enhance this patch. :)
was (Author: yzlai):
The remap_redirect URL is used inside of build_error_response(), which set
correct Location header for building response body with %{Location}psh
field.
If this Location header is set after calling build_error_response(), response
body will have empty %{Location}psh field because it was already generated.
{code}
+ if ((status_code == HTTP_STATUS_TEMPORARY_REDIRECT ||
+ status_code == HTTP_STATUS_MOVED_TEMPORARILY ||
+ status_code == HTTP_STATUS_MOVED_PERMANENTLY)
+ s-remap_redirect) {
+s-hdr_info.client_response.value_set(MIME_FIELD_LOCATION,
MIME_LEN_LOCATION, s-remap_redirect, strlen(s-remap_redirect));
+ }
{code}
I'm not that familiar with passing additional parameter, remap_redirect_len
here, while calling build_error_response().
Please feel free to enhance this patch. :)
404 error was logged while url redirect request was processed corrctly
--
Key: TS-2344
URL: https://issues.apache.org/jira/browse/TS-2344
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Eddie
Assignee: Leif Hedstrom
Labels: Review
Fix For: 5.0.0
Attachments: no_redirect_after_map.patch
I am seeing a lot of entries in the error log for my url redirect request.
The request was processed correctly and I could see the expected response in
log as below:
2013-11-08 18:23:37 IP 301 FIN http://yahoo.com
http://www.yahoo.com/
But log messages like following were printed in the error log too, which
generates a lot of error logs (log rotation configured) and filling up disk
space pretty fast.
20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on
Accelerator) for 'http:///'
20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect)
for 'http:///'
I watched my tcpdump log and did not see that the 404 error was sent out at
all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in
the error log for my url redirect request. The request was processed correctly
I could see the expected response in log as well:
2013-11-08 18:23:37 IP 301 FIN http://yahoo.com
http://www.yahoo.com/
But log messages like following were printed too:
20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on
Accelerator) for 'http:///'
20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect)
for 'http:///'
I watched my tcpdump log and did not see that the 404 error was sent out at
all. I am using ATS/3.2.4 and following
is the log configuration.
CONFIG proxy.config.log.logging_enabled INT 3
CONFIG proxy.config.log.max_secs_per_buffer INT 1
CONFIG proxy.config.log.max_space_mb_for_logs INT 25000
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
CONFIG proxy.config.log.max_space_mb_headroom INT 1000
CONFIG proxy.config.log.hostname STRING localhost
CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver
CONFIG proxy.config.log.logfile_perm STRING rw-r--r--
CONFIG proxy.config.log.custom_logs_enabled INT 1
CONFIG proxy.config.log.squid_log_enabled INT 0
CONFIG
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000812#comment-14000812 ] portl4t commented on TS-2723: - I agree to get rid of TCL, and we should use other ways to implement ts.shared.DICT. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000893#comment-14000893 ] Adam W. Dace commented on TS-2274: -- Actually that first document is there to help new users just get ATS up and running as a forward-only proxy(i.e. squid replacement). There's another document, WebProxyCacheTuning that goes into internal settings more thoroughly. Let me know if I can be of help, but just FYI those settings have only been tested and are being used on a forward-only proxy cache. Also, I'm the only user of said cache...not sure if they scale properly. :( Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2803) Use documentation strings extracted from source files in project documentation
[ https://issues.apache.org/jira/browse/TS-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000952#comment-14000952 ] ASF GitHub Bot commented on TS-2803: GitHub user jablko opened a pull request: https://github.com/apache/trafficserver/pull/87 TS-2803: Use documentation strings extracted from source files in projec... ...t documentation I rebased and added doxygen and python-lxml to contrib/manifests/debian.pp, next to python-sphinx. None of the other manifests mentions Sphinx. I updated doxygen.py to issue warnings if the Python lxml library isn't installed but so far I haven't added anything to checkvers.py. If the library is missing, warnings are issued and the extra strings are just omitted from the built documentation. I guess I'll have one or two tweaks to commit after we get a look at the Read the Docs build log, but based on what I've read it will work. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jablko/trafficserver TS-2803 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/87.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #87 commit 7a97a8e935ed39be5d5b47e06191eaaf9567650a Author: Jack Bates j...@nottheoilrig.com Date: 2014-05-13T16:51:53Z TS-2803: Use documentation strings extracted from source files in project documentation Use documentation strings extracted from source files in project documentation -- Key: TS-2803 URL: https://issues.apache.org/jira/browse/TS-2803 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Jack Bates Assignee: James Peach Fix For: 5.0.0 Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructuredText, and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2817) ATS crash in SSLNetVConnection::load_buffer_and_write
Sudheer Vinukonda created TS-2817:
-
Summary: ATS crash in SSLNetVConnection::load_buffer_and_write
Key: TS-2817
URL: https://issues.apache.org/jira/browse/TS-2817
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Our production host running latest master crashed with the below stack traces.
Based on the stack traces, this might be related to a recent jira TS-2815.
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b8c4da4f500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6fbb6f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x368)[0x70f938]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b8c4da47851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[example_alarm_bin.sh] sent alarm: l10.ycs.sjb.yahoo.com [Sat May 17 20:13:29
2014] The TS-TM connection is broken for some reason. Either restart TS and TM
or correct this error for TM
to display TS statistics correctly
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2aed4fbcc500]
/lib64/libc.so.6(memcpy+0x15b)[0x3296e8997b]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x2f)[0x60f11f]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x6114e0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x61d1e2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPKc+0x319)[0x628ba9]
/home/y/bin/traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x5e)[0x6295be]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x5d8)[0x599ce8]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x7a0)[0x5a4a40]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x188)[0x5a4dc8]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xe0)[0x5e7050]
/home/y/bin/traffic_server[0x70d6f1]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x95b)[0x70ff2b]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2aed4fbc4851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2812: -- Attachment: ts2812.diff Fixed the typo TSRemapDeleteInstance() header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2812: -- Attachment: (was: ts2812.diff) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000990#comment-14000990 ] Sudheer Vinukonda edited comment on TS-2812 at 5/18/14 4:14 AM: James - thanks for the input; So, are you suggesting to ALWAYS use camel case headers? The main idea behind writing this plugin is that, this should only be required/used on a need basis and only in the interim, while the legacy systems are being enhanced to accept headers in any case. On the other hand, if we change the implementation to ALWAYS send camel case headers, that would be incompatible with HTTP2 (HTTP/2 mandates the sender to use lowercase headers (and the receiver to do a case-insensitive comparison) as well as inefficient, when not required, right? http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1.3 Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. was (Author: sudheerv): James - thanks for the input; So, are you suggesting to ALWAYS use camel case headers? The main idea behind writing this plugin is that, this should only be required/used on a need basis and only in the interim, while the legacy systems enhance to accept headers in any case. On the other hand, if we change the implementation to ALWAYS send camel case headers, that would be incompatible with HTTP2 (HTTP/2 mandates the sender to use lowercase headers (and the receiver to do a case-insensitive comparison) as well as inefficient, when not required, right? http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1.3 Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000990#comment-14000990 ] Sudheer Vinukonda edited comment on TS-2812 at 5/18/14 4:15 AM: James - thanks for the input; So, are you suggesting to ALWAYS use camel case headers? The main idea behind writing this plugin is that, this should only be required/used on a need basis and only in the interim, while the legacy systems are being enhanced to accept headers in any case. On the other hand, if we change the implementation to ALWAYS send camel case headers, that would be eventually incompatible with HTTP2 (HTTP/2 mandates the sender to use lowercase headers and the receiver to do a case-insensitive comparison) as well as inefficient, when not required, right? http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1.3 Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. was (Author: sudheerv): James - thanks for the input; So, are you suggesting to ALWAYS use camel case headers? The main idea behind writing this plugin is that, this should only be required/used on a need basis and only in the interim, while the legacy systems are being enhanced to accept headers in any case. On the other hand, if we change the implementation to ALWAYS send camel case headers, that would be incompatible with HTTP2 (HTTP/2 mandates the sender to use lowercase headers (and the receiver to do a case-insensitive comparison) as well as inefficient, when not required, right? http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1.3 Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2818) TSHttpTxnServerAddrSet() doesn't update the server port
Sudheer Vinukonda created TS-2818: - Summary: TSHttpTxnServerAddrSet() doesn't update the server port Key: TS-2818 URL: https://issues.apache.org/jira/browse/TS-2818 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Sudheer Vinukonda Need to enhance TSHttpTxnServerAddrSet() to also update the server port. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000990#comment-14000990 ] Sudheer Vinukonda commented on TS-2812: --- James - thanks for the input; So, are you suggesting to ALWAYS use camel case headers? The main idea behind writing this plugin is that, this should only be required/used on a need basis and only in the interim, while the legacy systems enhance to accept headers in any case. On the other hand, if we change the implementation to ALWAYS send camel case headers, that would be incompatible with HTTP2 (HTTP/2 mandates the sender to use lowercase headers (and the receiver to do a case-insensitive comparison) as well as inefficient, when not required, right? http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1.3 Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
