400 Error bad request
Hi, I am getting the following error... Error 400 Bad Request. for ICAP Reqmod message. Here's a snippet of the example ICAP client code.. request =GET http://www.foobar.com http://www.foobar.com/ http://www.foobar.com/ http://www.foobar.com/ HTTP/1.1\r; output.println(REQMOD icap:// + server + : + 1344 + /+ REQMOD + + 1.0 +\r); output.println(Host: + server + : + port + \) output.println(Encapsulated: req-hdr=0, null-body= + length); output.println(Preview: 0\r); output.println(Allow: 204\r); output.println(\r); output.println(request); output.println(\r); Appreciate any help on this...this is a very simple ICAP client and i use the same format for sending ICAP options message and that works...for some reason REQMOD is getting rejected as bad request=8A Thanks, -Vikram.
Re: 400 Error bad request
On 11/07/2011 02:15 AM, Vikram Kumar wrote: I am getting the following error... Error 400 Bad Request. for ICAP Reqmod message. Here's a snippet of the example ICAP client code.. request =GET http://www.foobar.com http://www.foobar.com/ http://www.foobar.com/ http://www.foobar.com/ HTTP/1.1\r; output.println(REQMOD icap:// + server + : + 1344 + /+ REQMOD + + 1.0 +\r); output.println(Host: + server + : + port + \) output.println(Encapsulated: req-hdr=0, null-body= + length); output.println(Preview: 0\r); output.println(Allow: 204\r); output.println(\r); output.println(request); output.println(\r); Appreciate any help on this...this is a very simple ICAP client and i use the same format for sending ICAP options message and that works...for some reason REQMOD is getting rejected as bad request=8A Hello Vikram, I recommend that you post questions about writing ICAP clients to ICAP Forum as they are not related to Squid. If you repost your question there, consider posting the actual headers (instead of the code that produces them) and use plain text. You can collect the headers using tcpdump, wireshark, server logs, etc. I would also double check whether you are sending the protocol name (ICAP) on the first request line, whether you want \ on the Host: header line, and whether you need an extra CRLF after the HTTP request. However, please do not discuss those issues here. Instead, capture the actual request, carefully compare with valid ICAP requests, and post any questions to the ICAP Forum. Good luck, Alex.
Re: [PATCH] log format tokens upgrade
On 11/05/2011 05:13 AM, Amos Jeffries wrote:
This updates the format parser and storage objects in the Format::
namespace and separates some into separate files for SourceLayout
project dependency reductions.
Functionally it adds a registration API so components can register
themselves an array of tokens in a namespace. Registering the arbitrary
namespace example with some tokens (a,b) will cause the parser to
accept those tokens in a logging format like so: %example::a %example::b.
Due to time limitations resolving the library-library symbol
perculiarities in GCC I have had to cut short of moving the adapt::
and icap:: tokens into their libraries. But have gone so far as to
make them use the registration process in this patch ready for that step.
Future work:
- convert the error pages to use format for the page body macros
- convert the %ssl_* tokens in src/ssl/* to use format and the
namespace ssl::
- convert external_acl_type to use formats for its helper input string.
Amos
+explicit TokenNamespace(const String nsName, TokenTableEntry const
*tSet) : prefix(nsName), tokenSet(tSet) {};
No explicit for constructors with more than one required parameter
because they cannot be activated implicitly.
+~TokenNamespace() {};
Extra semicolon.
Not needed as the default destructor is the same.
+/// array of tokens inside this namespace
+TokenTableEntry const *tokenSet;
AFAICT, 3rd-party code modifies this set. Should we prohibit copying and
assigning of TokenNamespace objects then?
+class FmtConfig
+{
+public:
The new class needs a description, especially if we declare a global of
its type later:
+extern FmtConfig TheConfig;
+#define free_format(X) do{ delete (*X).formats; (*X).formats=NULL;
}while(false)
Technically, you need parens around X above.
-{st, LFT_ICAP_BYTES_READ},
+{st, LFT_ICAP_BYTES_SENT},
+{st, LFT_ICAP_BYTES_READ},
{bs, LFT_ICAP_BODY_BYTES_READ},
{h, LFT_ICAP_REQ_HEADER},
{h, LFT_ICAP_REP_HEADER},
{tr, LFT_ICAP_TR_RESPONSE_TIME},
-{tio, LFT_ICAP_IO_TIME},
+{tio, LFT_ICAP_IO_TIME},
{to, LFT_ICAP_OUTCOME},
{Hs, LFT_ICAP_STATUS_CODE},
-{NULL, LFT_NONE} /* this must be last */
+{NULL, LFT_NONE}/* this must be last */
Whitespace non-changes?
+class TokenTableEntry {
The new class needs a description. There is a broader description for
namespace Format above it, but we should define what this specific
class is for.
+const char *config;
+ByteCode_t token_type;
+int options;
Please document these. They are probably obvious to you, but some of us
need a hand to know what yet another config really is in this context.
=== modified file 'src/main.cc'
--- src/main.cc 2011-11-03 10:02:02 +
+++ src/main.cc 2011-11-05 09:41:52 +
@@ -63,6 +63,7 @@
#include event.h
#include EventLoop.h
#include ExternalACL.h
+#include format/Token.h
#include fs/Module.h
#include PeerSelectState.h
#include Store.h
@@ -1105,6 +1106,8 @@
// TODO: pconn is a good candidate for new-style registration
// PconnModule::GetInstance()-registerWithCacheManager();
// moved to PconnModule::PconnModule()
+
+Format::Token::Init();
}
if (IamPrimaryProcess()) {
Consider removing this dependency or even Format::Token::Init() as such
by using RunnersRegistry API. I understand you may not have time for
that, but perhaps you can add a corresponding TODO to discourage more
code being added to Format::Token::Init()?
=== renamed file 'src/format/Tokens.h' = 'src/format/Token.h'
--- src/format/Tokens.h 2011-10-13 17:05:25 +
+++ src/format/Token.h2011-11-05 08:38:12 +
@@ -1,5 +1,7 @@
-#ifndef _SQUID_FMT_TOKENS_H
-#define _SQUID_FMT_TOKENS_H
+#ifndef _SQUID_FORMAT_TOKEN_H
+#define _SQUID_FORMAT_TOKEN_H
+
+#include format/TokenTableEntry.h
Can you avoid this dependency by pre-declaring class TokenTableEntry? It
looks like we are only using a pointer to TokenTableEntry in
src/format/Token.h, no?
The above are all minor polishing touches. I did not see any bugs, and I
cannot say I understand this code well enough to find them.
Thank you,
Alex.
Re: [PATCH] Logging of honored certificate validation error names
On 11/05/2011 04:15 PM, Amos Jeffries wrote: On 2/11/2011 11:13 p.m., Tsantilas Christos wrote: Currently the %err_detail access_log formating code does not display something useful for the system admin in the case of the certificate validation errors. This patch in the case of an ERR_SECURE_CONNECT_FAIL error displays the certificate validation error name. +1. Looks okay. I'm a little dubious about passing request-detailError() the SSL error code instead of the errno. But have no strong objections. Error detailing code was specifically designed to record context-specific details beyond errno (which was already available in most cases) and the request-detailError() method itself is usually used to store non-errno details: ./src/Server.cc:request-detailError(ERR_ICAP_FAILURE, ERR_DETAIL_RESPMOD_BLOCK_LATE); ./src/client_side_request.cc:request-detailError(ERR_ACCESS_DENIED, ERR_DETAIL_REQMOD_BLOCK); ./src/client_side_request.cc:request-detailError(ERR_ICAP_FAILURE, ERR_DETAIL_CLT_REQMOD_RESP_BODY); ./src/client_side_request.cc:request-detailError(ERR_ICAP_FAILURE, errDetail); We even document HttpRequest::errDetail to be errType-specific: err_type errType; int errDetail; /// errType-specific detail about the transaction error Why are you dubious about passing request-detailError() the SSL error code? Thank you, Alex.
Re: Reading ACL configuration files every request
On 11/05/2011 06:39 PM, Andrew Beverley wrote: Hi, I am using the ACL feature whereby the parameters can be read from a file. For example: acl session_day time /var/www/announce_days.txt Understandably, the file only appears to be read when the configuration file is parsed, rather than each time the ACL is checked. However, I need it to be checked more often, as I have a system configuration interface that writes a day of the week to the file, which subsequently causes a splash page to be shown on a particular day. I would like configuration to be done without having to reload the Squid configuration file. Would any consideration be given to a patch to check the ACL file more often? Could/should it be an extra configuration option to check the file each request? I appreciate that this would come with a greater overhead. Is there a better way to achieve this? I know you have already written a special every-request helper to solve this per Amos' suggestion. FWIW, the usual approach (in a helper or elsewhere) is to reread the configuration file only when the file modification time stamp changes and/or a HUP signal is received, and not on every request. HTH, Alex.
Re: [PATCH] Detail SSL handshake failures
If there is not any objection I will commit this patch to trunk... On 11/02/2011 12:24 PM, Tsantilas Christos wrote: This patch allows Squid to provide details for the %D macro on the secure connect failed error page when an SSL handshake with the origin server fails. The default %D text is Handshake with SSL server failed: XYZ where XYZ is the corresponding error string/description returned by OpenSSL if there is any. This is a Measurement Factory project.
Re: [PATCH] [RFC] pconn directive cleanup
On 11/06/2011 11:12 PM, Amos Jeffries wrote: + This is only relevant when persistent client connections + are enabled. Non-persistent connections will close + immediately after each request is completed. I would remove the above addition as obvious and slightly awkward OR rephrase it to just say something like This option does not affect non-persistent client connections which are closed immediately after last use. The patch looks good to me. It would be useful to document whether setting the timeout to zero is meaningful as a way to optimize one-after-another requests without creating a lot of idle persistent connections. Thank you, Alex.
Re: [PATCH] Logging of honored certificate validation error names
On Mon, 07 Nov 2011 13:48:46 -0700, Alex Rousskov wrote: On 11/05/2011 04:15 PM, Amos Jeffries wrote: On 2/11/2011 11:13 p.m., Tsantilas Christos wrote: Currently the %err_detail access_log formating code does not display something useful for the system admin in the case of the certificate validation errors. This patch in the case of an ERR_SECURE_CONNECT_FAIL error displays the certificate validation error name. +1. Looks okay. I'm a little dubious about passing request-detailError() the SSL error code instead of the errno. But have no strong objections. Error detailing code was specifically designed to record context-specific details beyond errno (which was already available in most cases) and the request-detailError() method itself is usually used to store non-errno details: ./src/Server.cc:request-detailError(ERR_ICAP_FAILURE, ERR_DETAIL_RESPMOD_BLOCK_LATE); ./src/client_side_request.cc: request-detailError(ERR_ACCESS_DENIED, ERR_DETAIL_REQMOD_BLOCK); ./src/client_side_request.cc: request-detailError(ERR_ICAP_FAILURE, ERR_DETAIL_CLT_REQMOD_RESP_BODY); ./src/client_side_request.cc: request-detailError(ERR_ICAP_FAILURE, errDetail); We even document HttpRequest::errDetail to be errType-specific: err_type errType; int errDetail; /// errType-specific detail about the transaction error Why are you dubious about passing request-detailError() the SSL error code? That in this case we seem to have both an errno and an extended error with values. Its not clear to me whether this change is keeping the system errno around for the report tokens which display pure errno (or '-') rather than our extended err_type. Not a major issue since I think our err_type is a clearer message anyway. Amos
Re: Reading ACL configuration files every request
On Mon, 2011-11-07 at 13:55 -0700, Alex Rousskov wrote: FWIW, the usual approach (in a helper or elsewhere) is to reread the configuration file only when the file modification time stamp changes and/or a HUP signal is received, and not on every request. Thanks, I hadn't thought of that. Now incorporated into my helper! Andy
Re: [PATCH] Logging of honored certificate validation error names
On 11/07/2011 03:58 PM, Amos Jeffries wrote: On Mon, 07 Nov 2011 13:48:46 -0700, Alex Rousskov wrote: On 11/05/2011 04:15 PM, Amos Jeffries wrote: On 2/11/2011 11:13 p.m., Tsantilas Christos wrote: Currently the %err_detail access_log formating code does not display something useful for the system admin in the case of the certificate validation errors. This patch in the case of an ERR_SECURE_CONNECT_FAIL error displays the certificate validation error name. +1. Looks okay. I'm a little dubious about passing request-detailError() the SSL error code instead of the errno. But have no strong objections. Error detailing code was specifically designed to record context-specific details beyond errno (which was already available in most cases) and the request-detailError() method itself is usually used to store non-errno details: ./src/Server.cc:request-detailError(ERR_ICAP_FAILURE, ERR_DETAIL_RESPMOD_BLOCK_LATE); ./src/client_side_request.cc: request-detailError(ERR_ACCESS_DENIED, ERR_DETAIL_REQMOD_BLOCK); ./src/client_side_request.cc: request-detailError(ERR_ICAP_FAILURE, ERR_DETAIL_CLT_REQMOD_RESP_BODY); ./src/client_side_request.cc: request-detailError(ERR_ICAP_FAILURE, errDetail); We even document HttpRequest::errDetail to be errType-specific: err_type errType; int errDetail; /// errType-specific detail about the transaction error Why are you dubious about passing request-detailError() the SSL error code? That in this case we seem to have both an errno and an extended error with values. Its not clear to me whether this change is keeping the system errno around for the report tokens which display pure errno (or '-') rather than our extended err_type. Not a major issue since I think our err_type is a clearer message anyway. Christos, I think your patch does not change pure errno rendering for error pages where we have separate macros for displaying errno and error detail, right? For access logs, we do not have separate macros so we have to log what is most relevant. In case of a certificate validation errors, the SSL validation error is more relevant than system errno, which is often not set for those errors, correct? When/if access log gains all the error page macros, the admin would be able to log the system errno separately from the SSL error name. Thank you, Alex.
Re: [PATCH] Detail SSL handshake failures
On 11/07/2011 02:02 PM, Tsantilas Christos wrote: If there is not any objection I will commit this patch to trunk... Please do. While you are at it, please consider changing SslErrorDetailDefaultStr, the default error description, from SSL certificate validation error (%err_name): %ssl_subject to SSL handshake error (%err_name) because that default is now used for more than just validation errors and because most handshake errors that are not validation errors will lack %ssl_subject. Thank you, Alex. On 11/02/2011 12:24 PM, Tsantilas Christos wrote: This patch allows Squid to provide details for the %D macro on the secure connect failed error page when an SSL handshake with the origin server fails. The default %D text is Handshake with SSL server failed: XYZ where XYZ is the corresponding error string/description returned by OpenSSL if there is any. This is a Measurement Factory project.
Re: Override FD on windows
lör 2011-11-05 klockan 12:02 +0200 skrev Ghassan Gharabli: I am working on a project with a friend to try exceeding the limitation of File Descriptors on Windows.. From what I remember the limit comes from a Visual Studio crt limitation. But I only have vague memory of what Guido have said many years ago. the source for the Visual Studio crt is available I think and can be rebuilt. Whats the difference between compiling Squid as : ( Cygwin , MinGW , MS VISUAL STUDIO)? MinGW is a native build using GNU toolchain. Visual Studio is a native build ising Microsoft toolchain. The result of both is similar native Windows appliacations. Cygwin is POSIX emulated build using a GNU toolchain, heavily relying on the cygwin dll för providing POSIX like functionality. Not needed for Squid as it has native Windows support. I would like to hear suggestions from you concerning Squid2.7 STABLE9. Upgrade. Squid-2 is very near end of life. Squid-3 needs more windows knowing people looking at it, and anything you can contribute there will be of help. Regards Henrik
Re: 400 Error bad request
Thanks Alex will do that .. Sent from cellphone On Nov 7, 2011, at 12:04 PM, Alex Rousskov rouss...@measurement-factory.com wrote: On 11/07/2011 02:15 AM, Vikram Kumar wrote: I am getting the following error... Error 400 Bad Request. for ICAP Reqmod message. Here's a snippet of the example ICAP client code.. request =GET http://www.foobar.com http://www.foobar.com/ http://www.foobar.com/ http://www.foobar.com/ HTTP/1.1\r; output.println(REQMOD icap:// + server + : + 1344 + /+ REQMOD + + 1.0 +\r); output.println(Host: + server + : + port + \) output.println(Encapsulated: req-hdr=0, null-body= + length); output.println(Preview: 0\r); output.println(Allow: 204\r); output.println(\r); output.println(request); output.println(\r); Appreciate any help on this...this is a very simple ICAP client and i use the same format for sending ICAP options message and that works...for some reason REQMOD is getting rejected as bad request=8A Hello Vikram, I recommend that you post questions about writing ICAP clients to ICAP Forum as they are not related to Squid. If you repost your question there, consider posting the actual headers (instead of the code that produces them) and use plain text. You can collect the headers using tcpdump, wireshark, server logs, etc. I would also double check whether you are sending the protocol name (ICAP) on the first request line, whether you want \ on the Host: header line, and whether you need an extra CRLF after the HTTP request. However, please do not discuss those issues here. Instead, capture the actual request, carefully compare with valid ICAP requests, and post any questions to the ICAP Forum. Good luck, Alex.
