Re: [Catalyst] Request: Wrong Content-Length value: 2628941
On Sun, Nov 15, 2009 at 8:07 AM, Tomas Doran wrote:
>
>
>> Could this message be updated to report the length of the body read, too?
>> And maybe display the last X bytes of data read might be useful in some
>> cases.
>>
>
> You haven't told us what the error actually is?
Did you miss the subject of the message? Or do you mean why I got the error
I quoted in the subject? I'm not sure why I got the error. I see it
somewhat often, but I'm not sure if it's a client overstating the content
length or something else. That's why I was asking about having the error
provide more info.
while ( my $buffer = $self->read($c) ) {
$c->prepare_body_chunk($buffer);
}
# paranoia against wrong Content-Length header
my $remaining = $length - $self->read_position;
if ( $remaining > 0 ) {
$self->finalize_read($c);
Catalyst::Exception->throw(
"Wrong Content-Length value: $length" );
}
So, either read returned false before it should have (seems unlikely it
would be empty string or zero) or client overstated. Again, I tend to get a
separate error if the client aborts.
Can you think of how that error might be more informative? Might be
somewhat helpful to see the last chunk from read or the body.
E.g. Expected $content_length bytes but read only $body_length. Last 100
bytes are: $last_chunk.
--
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Request: Wrong Content-Length value: 2628941
On 15 Nov 2009, at 14:55, Bill Moseley wrote:
I see this error every once in a while. It does not seem like an
aborted connection (I get a different error for that). Is there any
other reason why the read() method might returning false before done.
while ( my $buffer = $self->read($c) ) {
$c->prepare_body_chunk($buffer);
}
I suppose if $buffer just happened to be zero. Probably should be
checking defined there.
Yep, that should be fixed.
Could this message be updated to report the length of the body read,
too? And maybe display the last X bytes of data read might be
useful in some cases.
You haven't told us what the error actually is?
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] show_internal_actions => 1
On 15 Nov 2009, at 13:09, Kiffin Gish wrote: On Sun, 2009-11-15 at 03:07 -0800, Jacob Helwig wrote: Unless that's a typo in "show_internal_actions => 0", then you probably haven't actually enabled it. I'm guessing you actually want "show_internal_actions => 1". Yes that's a typo. Should be a 0, same question as before. You mean should be 1? The effect you get is that internal actions such as _DISPATCH are shown in the debug table... Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] attrs for DBIx::Class::Row
On 15 Nov 2009, at 11:20, Octavian Râşniţă wrote:
After I constructed a resultset object, I can get the hash of
attributes used for generating it using:
my $attrs = $rs->{attrs}
Erm, this is a bad move, you're breaking abstraction here..
But if I get a row object from that resultset, I can't get the
attributes anymore using:
my $row = $rs->first;
my $attrs = $row->{attrs};
Is there a way of getting the attributes used for searching,
ordering, paginating... from a row object?
You're better asking the DBIC list about DBIC issues..
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
From: "Stephan Jauernick" Hi, I would suggest you: http://search.cpan.org/~stephanj/Catalyst-TraitFor-Request-PerLanguageDomains-0.01/lib/Catalyst/TraitFor/Request/PerLanguageDomains.pm I have seen it, but it recognize the languages from the domain names and if I'd use this type of URL naming it would be harder to use an SSL key. I know that there are SSL keys that can be used for more subdomains, but I don't have one like that. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] attrs for DBIx::Class::Row
2009/11/15 Octavian Râşniţă
> Hi,
>
> After I constructed a resultset object, I can get the hash of attributes
> used for generating it using:
> my $attrs = $rs->{attrs}
>
> But if I get a row object from that resultset, I can't get the attributes
> anymore using:
>
> my $row = $rs->first;
> my $attrs = $row->{attrs};
>
> Is there a way of getting the attributes used for searching, ordering,
> paginating... from a row object?
>
> I want to use those attributes for generating a digest key in order to
> store the object in the cache, and I need to get those attributes after I
> created the row object.
>
> Thank you.
>
> Octavian
>
>
>
>
You seem to have accidentally posted to the Catalyst mailing list, the
DBIx::Class mailing list is at
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
On Sun, Nov 15, 2009 at 7:23 AM, Joel Bernstein wrote: > On 15 Nov 2009, at 15:06, Bill Moseley wrote: > > > > > What's your preferred approach to specifying a language tag in a URL? Is > there strong argument for one over the other? > > > > http://example.com/en_us/path/to/some/index.html # language prefix > > > > http://example.com/path/to/some/index.html?lang=en_us > > No no no! Allow the client and server to negotiate what content to serve > for the resource identified. As a URI to a resource which may vary according > to many dimensions, /path/to/some/content is fine. > I use that as a fallback, but in practice auto-detection doesn't work as well as one would hope. In fact I think I disabled that code because of all the headaches. Turns out the browser is not very good at understanding the user running the browser at that moment, or the user's preference for a given page.We also had problems with caching of pages in the wrong language. At one point we would set a flag in the session, too, but that had problems (with proxy caching IIRC). > If you really must stick it in the URL, I'd go for something like: > /path/to/content/en > /path/to/content/pt_BR > etc > I prefer the prefix to that. Makes it transparent to the applicaiton and relative URLs work. > > A better question is: what kind of problems are you solving where > server-driven or agent-driven content negotiation as described in the HTTP > 1.1 RFC (an excellent and very readable document, honestly) are > insufficient? > The quesiton was just between using a query parameter vs. a path segment. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
Hi, I would suggest you: http://search.cpan.org/~stephanj/Catalyst-TraitFor-Request-PerLanguageDomains-0.01/lib/Catalyst/TraitFor/Request/PerLanguageDomains.pm Octavian Râsnita schrieb: > From: "Joel Bernstein" > > On 15 Nov 2009, at 15:06, Bill Moseley wrote: > >> >> What's your preferred approach to specifying a language tag in a URL? >> Is there strong argument for one over the other? >> >> http://example.com/en_us/path/to/some/index.html # language prefix >> >> http://example.com/path/to/some/index.html?lang=en_us > > No no no! Allow the client and server to negotiate what content to serve > for the resource identified. As a URI to a resource which may vary > according to many dimensions, /path/to/some/content is fine. > > GET /path/to/content HTTP/1.1 > Accept-Language: en > Accept: text/html > > A better question is: what kind of problems are you solving where > server-driven or agent-driven content negotiation as described in the > HTTP 1.1 RFC (an excellent and very readable document, honestly) are > insufficient? > > /joel > > The most important reason I needed to use URLS like /en/dir/file, > /ro/dir/file was the fact that very many users, although they don't know > English, they use the browser with the default configurations so they > see the pages in English and then they don't like it and want to change it. > > So I use the following rules (in order) for choosing the current language: > 1. The language chosen by the user by clicking the wanted flag; > 2. The language which is specified in the URL like /ro/dir/file; > 3. The language prefered by the browser; > 4. The default language (if the site doesn't offer translation for the > browser-prefered language, or if there is no browser-prefered language). > > Using different URLS for different pages might help search engines to > index the site, because otherwise the search engines might not try to > access the site with all possible languages in order to see if the web > site offers content in those languages. > > (There may be other solutions for this, like specifying the alternate > versions of the page as meta tags or something like that, but I don't > know how to do that or if it is possible.) > > Octavian > > > > > > > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
From: "Joel Bernstein" On 15 Nov 2009, at 15:06, Bill Moseley wrote: What's your preferred approach to specifying a language tag in a URL? Is there strong argument for one over the other? http://example.com/en_us/path/to/some/index.html # language prefix http://example.com/path/to/some/index.html?lang=en_us No no no! Allow the client and server to negotiate what content to serve for the resource identified. As a URI to a resource which may vary according to many dimensions, /path/to/some/content is fine. GET /path/to/content HTTP/1.1 Accept-Language: en Accept: text/html A better question is: what kind of problems are you solving where server-driven or agent-driven content negotiation as described in the HTTP 1.1 RFC (an excellent and very readable document, honestly) are insufficient? /joel The most important reason I needed to use URLS like /en/dir/file, /ro/dir/file was the fact that very many users, although they don't know English, they use the browser with the default configurations so they see the pages in English and then they don't like it and want to change it. So I use the following rules (in order) for choosing the current language: 1. The language chosen by the user by clicking the wanted flag; 2. The language which is specified in the URL like /ro/dir/file; 3. The language prefered by the browser; 4. The default language (if the site doesn't offer translation for the browser-prefered language, or if there is no browser-prefered language). Using different URLS for different pages might help search engines to index the site, because otherwise the search engines might not try to access the site with all possible languages in order to see if the web site offers content in those languages. (There may be other solutions for this, like specifying the alternate versions of the page as meta tags or something like that, but I don't know how to do that or if it is possible.) Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
From: "Bill Moseley" What's your preferred approach to specifying a language tag in a URL? Is there strong argument for one over the other? http://example.com/en_us/path/to/some/index.html # language prefix http://example.com/path/to/some/index.html?lang=en_us I prefer the former way because the URL looks nicer. (Not a very "strong" argument:) Are pages in different languages different resources or different versions of the same resource? In most cases I think it is the same content with a different presentation style, language... Obviously, the prefix is easier if you use relative URLs, but uri_for makes adding the query parameter easy. Although, probably could argue that the prefix approach is more efficient than wrapping uri_for for every generated link. There is an example on the Catalyst wiki for overriding prepare_path() in order to use urls like /en/path/to/another/file.html without needing to change all controllers. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
On 15/11/09 15:23, Joel Bernstein wrote: A better question is: what kind of problems are you solving where server-driven or agent-driven content negotiation as described in the HTTP 1.1 RFC (an excellent and very readable document, honestly) are insufficient? How do you easily change the Accept-Language header in $modern_browser[1] ? If I'm using my friend's laptop (he's a Finn), letting it choose to show me a page in Finnish isn't much use to me as I speak not a word. OK, so that's a slightly contrived example but equally important is making content in multiple languages accessible to search engine spiders. In this instance you need to be able to disambiguate the content via the URI since that is all you have. You need to provide them with a link to different language versions in the form of a URI since they don't spider the web multiple times with different Accept: headers to see what they get. As a content provider one has to be a bit more explicit about it. S. [1] I know how to do it in Firefox, no idea in other browsers and in the real world, clicking on a link that says "English" is easier than trying to work out the vagaries of each browser UI. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Language selection in URLs
On 15 Nov 2009, at 15:06, Bill Moseley wrote: > > What's your preferred approach to specifying a language tag in a URL? Is > there strong argument for one over the other? > > http://example.com/en_us/path/to/some/index.html # language prefix > > http://example.com/path/to/some/index.html?lang=en_us No no no! Allow the client and server to negotiate what content to serve for the resource identified. As a URI to a resource which may vary according to many dimensions, /path/to/some/content is fine. GET /path/to/content HTTP/1.1 Accept-Language: en Accept: text/html > Are pages in different languages different resources or different versions of > the same resource? They are different *representations* of the same *resource*. The dimension of variation in this case is the Accept-Language: request header. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4 and you might reasonably vary the content type returned according to the client's Accept: header too. > Obviously, the prefix is easier if you use relative URLs, but uri_for makes > adding the query parameter easy. Although, probably could argue that the > prefix approach is more efficient than wrapping uri_for for every generated > link. If you really must stick it in the URL, I'd go for something like: /path/to/content/en /path/to/content/pt_BR etc A better question is: what kind of problems are you solving where server-driven or agent-driven content negotiation as described in the HTTP 1.1 RFC (an excellent and very readable document, honestly) are insufficient? /joel ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Language selection in URLs
What's your preferred approach to specifying a language tag in a URL? Is there strong argument for one over the other? http://example.com/en_us/path/to/some/index.html # language prefix http://example.com/path/to/some/index.html?lang=en_us Are pages in different languages different resources or different versions of the same resource? Obviously, the prefix is easier if you use relative URLs, but uri_for makes adding the query parameter easy. Although, probably could argue that the prefix approach is more efficient than wrapping uri_for for every generated link. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Request: Wrong Content-Length value: 2628941
I see this error every once in a while. It does not seem like an aborted
connection (I get a different error for that). Is there any other reason
why the read() method might returning false before done.
while ( my $buffer = $self->read($c) ) {
$c->prepare_body_chunk($buffer);
}
I suppose if $buffer just happened to be zero. Probably should be checking
defined there.
Could this message be updated to report the length of the body read, too?
And maybe display the last X bytes of data read might be useful in some
cases.
--
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] show_internal_actions => 1
On Sun, 2009-11-15 at 03:07 -0800, Jacob Helwig wrote: > Unless that's a typo in "show_internal_actions => 0", then you > probably haven't actually enabled it. I'm guessing you actually want > "show_internal_actions => 1". Yes that's a typo. Should be a 0, same question as before. -- Kiffin Gish Gouda, The Netherlands ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] attrs for DBIx::Class::Row
Hi,
After I constructed a resultset object, I can get the hash of attributes
used for generating it using:
my $attrs = $rs->{attrs}
But if I get a row object from that resultset, I can't get the attributes
anymore using:
my $row = $rs->first;
my $attrs = $row->{attrs};
Is there a way of getting the attributes used for searching, ordering,
paginating... from a row object?
I want to use those attributes for generating a digest key in order to store
the object in the cache, and I need to get those attributes after I created
the row object.
Thank you.
Octavian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] show_internal_actions => 1
On Sun, Nov 15, 2009 at 02:59, Kiffin Gish wrote:
> Hi there.
>
> I've enable show_internal_actions but do not see any (obvious)
> difference in the debug output, what is it exactly that I should be
> seeing?
>
> __PACKAGE__->config(
> name => 'I4',
> session => { flash_to_stash => 1 },
> show_internal_actions => 0,
> );
>
> Thanks alot in advance,
> Kiffin
>
> --
> Kiffin Gish
> Gouda, The Netherlands
>
Unless that's a typo in "show_internal_actions => 0", then you
probably haven't actually enabled it. I'm guessing you actually want
"show_internal_actions => 1".
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] show_internal_actions => 1
Hi there.
I've enable show_internal_actions but do not see any (obvious)
difference in the debug output, what is it exactly that I should be
seeing?
__PACKAGE__->config(
name=> 'I4',
session => { flash_to_stash => 1 },
show_internal_actions => 0,
);
Thanks alot in advance,
Kiffin
--
Kiffin Gish
Gouda, The Netherlands
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
