date:20090629

GAE + Restlet issue

2009-06-29 Thread Matt

Hi there,

I'm trying to use GAE and Restlet together. All works fine on the local
development server. 


The first initial deploy to the "live" server worked fine. 

1.latest.[applicationid].appspot.com > works as expected.

However on my subsequent deploys I keep getting: 

1001.latest.[applicationid].appspot.com ---> fails with the following error
from the logs

#

org.restlet.Restlet handle: Unable to start the Restlet
java.lang.NullPointerException
at
org.restlet.engine.component.ComponentHelper.checkVirtualHost(ComponentHelper.java:89)
at
org.restlet.engine.component.ComponentHelper.start(ComponentHelper.java:183)
at org.restlet.Component.startHelper(Component.java:539)
at org.restlet.Component.start(Component.java:513)
at org.restlet.Restlet.handle(Restlet.java:172)
at org.restlet.Component.handle(Component.java:394)
at org.restlet.Server.handle(Server.java:350)
at org.restlet.engine.ServerHelper.handle(ServerHelper.java:69)
at
org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:149)
at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:932)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:237)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at
com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at
com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:125)
at
com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:235)
at
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:4755)
at
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:4753)
at
com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:359)
at com.google.net.rpc.impl.Server$2.run(Server.java:800)
at
com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56)
at
com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:510)
at com.google.net.rpc.impl.Server.startRpc(Server.java:756)
at com.google.net.rpc.impl.Server.processRequest(Server.java:348)
at
com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:459)
at
com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319)
at
com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290)
at com.google.net.async.Connection.handleReadEvent(Connection.java:419)
at
com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:762)
at
com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:207)
at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101)
at
com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251)
at
com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:373)
at java.lang.Thread.run(Unknown Source)

#
W 06-29 07:44PM 54.635

org.restlet.Restlet handle: Unable to start the Restlet

#
E 06-29 07:44PM 54.635

org.restlet.engine.ChainHelper handle: The org.restlet.Component class has
no Restlet defined to process calls. Maybe it wasn't properly sta

RE: Restlet trunk andd GWT issues...

2009-06-29 Thread Brian Anderson

FWIW, the following change in HttpClientConverter.java seems to fix the NPE:

public void commit(final HttpClientCall httpCall, Request request,
Response response, final Uniform userCallback) throws Exception {
if (httpCall != null) {
// Send the request to the client
httpCall.sendRequest(request, response, new Uniform() {

public void handle(Request request, Response response,
Uniform callback) {
updateResponse(response, httpCall);
userCallback.handle(request, response, null);
}

});
}
}


> Hello,
> 
> I am working with the GWT edition and trunk r5150 in order to get the recent 
> changes that fix content negotiation issues present in 2.0m3.
> 
> I have a simple GWT app loosely based upon the RestletGWTSimpleExample. I 
> notice that I cannot get my GWT app to run in hosted mode without changing 
> the source element in GWT.gwt.xml. The trunk version specifies:
> 
>   
> 
> which causes a "Non-canonical source path: ./" in the hosted mode browser 
> followed by numerous other derived errors. Changing the offending source 
> statement to:
> 
>   
> 
> apparently solves the issue.
> 
> I have not been able to find RestletGWTSimpleExample in the svn sources or on 
> the site other than through the link provided. Obviously there have been 
> changes made in the callback mechanism between 2.0m3 and the trunk version. 
> Attempting the following:
> 
> // Add an AJAX call to the server
> final Client client = new Client(Protocol.HTTP);
> client.get(PING_URL, new Uniform() {
> public void handle(Request request, Response response, Uniform 
> callback) {
>   pingText.setText(response.getEntity().getText());
> }
>   });
> 
> gets me past compilation issues but results in an NPE:
> 
> [ERROR] Uncaught exception escaped
> java.lang.NullPointerException: null
> at 
> org.restlet.engine.http.HttpClientConverter$1.handle(HttpClientConverter.java:384)
> at 
> org.restlet.engine.http.GwtHttpClientCall$2.onResponseReceived(GwtHttpClientCall.java:236)
> at 
> com.google.gwt.http.client.Request.fireOnResponseReceivedImpl(Request.java:264)
> 
> So, I am wondering if I have the callback pattern properly coded, or maybe 
> this isn't yet ready for prime time?
> 
> Also, it would be helpful if the RestletGWTSimpleExample source was in the 
> svn trunk and updated along with the core.
> 
> Thanks for any help you can provide.
> 
> ba

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366513

Re: Restlet v 1.1.5 multiple times allow method checked

2009-06-29 Thread Alin Popa

Thanks Jerome,

Now's more clear.

On Mon, Jun 29, 2009 at 11:30 AM, Jerome Louvel
wrote:

>  Hi Alin,
>
>
>
> The reason is simple: when a method is not allowed, HTTP expects the server
> to return the list of allowed methods, therefore the framework introspects
> the resource by calling allow*() methods.
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
>
>
>
>
>
>
> *De :* Alin Popa [mailto:alin.p...@gmail.com]
> *Envoyé :* mercredi 24 juin 2009 15:06
> *À :* discuss@restlet.tigris.org
> *Objet :* Restlet v 1.1.5 multiple times allow method checked
>
>
>
> Hi,
>
> Very soon I noticed something strange(?) when using Restlet Resources:
>
> if a http method is not allowed, it will go and check all allow methods:
> e.g.
>
> When using DELETE http method and only POST is allowed,  it will go and
> check
> allowDelete, allowGet, allowPut.
>
> Why is not doing just one check for allowDelete and stops ?
> Is this the normal behavior ? If yes, is there a way to suppress returned
> message within a Resource ?
>
>
> Thanks.
>
> --
> Regards,
>
> Alin
>



-- 
Regards,

Alin

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366288

Restlet trunk andd GWT issues...

2009-06-29 Thread Brian Anderson

Hello,

I am working with the GWT edition and trunk r5150 in order to get the recent 
changes that fix content negotiation issues present in 2.0m3.

I have a simple GWT app loosely based upon the RestletGWTSimpleExample. I 
notice that I cannot get my GWT app to run in hosted mode without changing the 
source element in GWT.gwt.xml. The trunk version specifies:

  

which causes a "Non-canonical source path: ./" in the hosted mode browser 
followed by numerous other derived errors. Changing the offending source 
statement to:

  

apparently solves the issue.

I have not been able to find RestletGWTSimpleExample in the svn sources or on 
the site other than through the link provided. Obviously there have been 
changes made in the callback mechanism between 2.0m3 and the trunk version. 
Attempting the following:

// Add an AJAX call to the server
final Client client = new Client(Protocol.HTTP);
client.get(PING_URL, new Uniform() {
public void handle(Request request, Response response, Uniform 
callback) {
  pingText.setText(response.getEntity().getText());
}
  });

gets me past compilation issues but results in an NPE:

[ERROR] Uncaught exception escaped
java.lang.NullPointerException: null
at 
org.restlet.engine.http.HttpClientConverter$1.handle(HttpClientConverter.java:384)
at 
org.restlet.engine.http.GwtHttpClientCall$2.onResponseReceived(GwtHttpClientCall.java:236)
at 
com.google.gwt.http.client.Request.fireOnResponseReceivedImpl(Request.java:264)

So, I am wondering if I have the callback pattern properly coded, or maybe this 
isn't yet ready for prime time?

Also, it would be helpful if the RestletGWTSimpleExample source was in the svn 
trunk and updated along with the core.

Thanks for any help you can provide.

ba

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366391

Re: Premature EOF / Broken Pipe

2009-06-29 Thread Timothy Aanerud

I haven't tried switching HTTP connectors. :-(

But, I did build a sanitized/stripped down example.  Unfortunately, my
example does not fail like my application does.   One difference between my
example is I'm only exchange data with one resource, In my actual
application I'm sending two messages to two resources back-to-back before
pausing.
--
Timothy Aanerud
taane...@aticonsulting.com


On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel wrote:

>  Hi Timothy,
>
>
>
> Were you able to make progress on this front?
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
> *De :* Timothy Aanerud [mailto:taane...@aticonsulting.com]
> *Envoyé :* vendredi 19 juin 2009 22:05
> *À :* discuss@restlet.tigris.org
> *Objet :* Re: Premature EOF / Broken Pipe
>
>
>
> No, I haven't tried switching HTTP connectors. I get the same failures for
> both HTTP and HTTPS.
> In another experiement, I changed the client message frequency to ~1 second
> intervals and at this rate on both
> Windows XP and Fedora10/Linux show now problems with the server running on
> Fedora.
>
> The various frequencies and failure rates:
> 1 second == no problems
> 1.5 seconds == ~25% failure rate
> 5 seconds == ~25% failure rate
> 10 seconds == ~3% failure rate
> 180 seconds == >0.5%, if any failures
>
> I'll switch the HTTP connectors out one at a time and see what happens.
> --
> Timothy Aanerud
>
>  On Fri, Jun 19, 2009 at 2:02 PM, Jerome Louvel 
> wrote:
>
> Hi Timothy,
>
> This looks like a bug to me. Have you tried with different Restlet HTTP
> connectors (such as Jetty on the server-side and Apache HTTP client)?
>
> If you could send us a simple standalone test case, we could easily debug
> what's going bad.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder~ http://www.noelios.com
>
>
> -Message d'origine-
> De: Timothy Aanerud [mailto:taane...@aticonsulting.com]
> Envoy頺 vendredi 19 juin 2009 18:18
> : discuss@restlet.tigris.org
> Objet: RE: Premature EOF / Broken Pipe
>
>
> As a test, I moved the client code to a Windows XP machine. With a five
> second update rate it fails regularly too, with the same exceptions and
> stack traces.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23635
> 62
>
> --
>
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363638
>
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366382

RE: Possible GAE Client issue.

2009-06-29 Thread Jerome Louvel

Hi guys,

By default, we leverage the HttpURLConnection class which has been
reimplemented on top of URLFetcher so this should work.

Thierry will finish his work on automated Restlet editions next week or so
and we'll be able to resolve such issue more quickly and precisely.

For now, I suggest to enter a bug report.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : news [mailto:n...@ger.gmane.org] De la part de Philippe Marschall
Envoyé : vendredi 26 juin 2009 07:14
À : discuss@restlet.tigris.org
Objet : Re: Possible GAE Client issue.

Matt wrote:
> Hi there,
> 
> I'm getting the following error whenever I attempt to use the client class
> from within the GAE.
> 
> Client client = new Client(Protocol.HTTP);
> Response response = client.get("http://www.google.com";);
> 
> Internal Connector Error (1002) - access denied (java.net.SocketPermission
> www.google.com resolve)
> 
> NB: I'm not using anything other than the default provided by restlet i.e.
> I'm not using apache's HttpClient.
> 
> I've updated the gae jar to be the latest snapshot as of yesterday but I'm
> still getting this problem.
> 
> Any suggestions? Or is it a potential bug? 

You're not allowed to open sockets on GAE/J.

Cheers
Philippe

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23655
93

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366277

RE: Content Negotiation for Safari 4. Any way to override?

2009-06-29 Thread Jerome Louvel

Hi all,

I don't think that keeping the equalsIgnoreCase() method call do any harm. I 
suggest to keep it for flexibility purpose.

I've checked the HTTP spec, but nothing is said about case sensitivity for 
product tokens:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com




-Message d'origine-
De : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : vendredi 26 juin 2009 07:54
À : discuss@restlet.tigris.org
Objet : Re: Content Negotiation for Safari 4. Any way to override?

Hello,

well, I'm afraid that I'm the author of the change...
Let's see with Jérôme if we keep the "equalsIgnorCase" test or not.

best regards,
Thierry Boileau

> Hello Bruno, Bruce,
>
> well that's weird, the current 2.0 release (in the svn repository) uses 
> "equalsIgnoreCase" not "equals". And I was not aware this had changed.
>
>
> best regards,
> Thierry Boileau
>   
>> Hi Bruce/Thierry,
>>
>> It seems that the code has changed between version 1.1 and 2.0.
>>
>> In 1.1.5, com.noelios.restlet.application.TunnelFilter uses 
>> 'equalsIgnoreCase' (line 388), whereas in the trunk (2.0), 
>> org.restlet.engine.application.TunnelFilter uses 'equals' (line 528).
>>
>> I think it makes sense to use 'equals' instead of 'equalsIgnoreCase' 
>> (although I'm not sure which one is best), but the accept.properties 
>> files should probably be updated to reflect this change (the version in 
>> the trunk still uses lower case for all agent names).
>>
>> Best wishes,
>>
>> Bruno.
>>
>> Bruce Cooper wrote:
>>   
>> 
>>> Hi guys,
>>>
>>> I have found that the agentName is reporting as Safari with a capitol S 
>>> whereas the standard file has it listed with a lowercase s, so I've 
>>> needed to add a separate rule in accept.properties.  Because I want to 
>>> only override the default Accept that is being sent through (and so that 
>>> I can put in other accepts in XMLHttpRequest requests and not have them 
>>> overridden)//, I think it is best to include the acceptOld as shown below://
>>>
>>> #Safari
>>> agentName: Safari
>>> acceptOld: 
>>> application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>>> acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>>
>>> This appears to work for me, so I'm happy.  Let me know if you think it 
>>> is a good solution.
>>>
>>> Bruce.
>>> 
>>>   
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2365378
>>
>>
>> 
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2365482
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2365596

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366276

RE: Restlet v 1.1.5 multiple times allow method checked

2009-06-29 Thread Jerome Louvel

Hi Alin,

 

The reason is simple: when a method is not allowed, HTTP expects the server
to return the list of allowed methods, therefore the framework introspects
the resource by calling allow*() methods.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com

 

 

 

 

 

De : Alin Popa [mailto:alin.p...@gmail.com] 
Envoyé : mercredi 24 juin 2009 15:06
À : discuss@restlet.tigris.org
Objet : Restlet v 1.1.5 multiple times allow method checked

 

Hi,

Very soon I noticed something strange(?) when using Restlet Resources:

if a http method is not allowed, it will go and check all allow methods:
e.g.

When using DELETE http method and only POST is allowed,  it will go and
check
allowDelete, allowGet, allowPut.

Why is not doing just one check for allowDelete and stops ?
Is this the normal behavior ? If yes, is there a way to suppress returned
message within a Resource ?


Thanks.

-- 
Regards,

Alin

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366273

RE: Problem Using proxy server for Restlet service

2009-06-29 Thread Jerome Louvel

Hi Albert, 

As a workaround, if you use the HTTP client connector based on
HttpURLConnection (org.restlet.ext.net), then you can use the proxy
parameters via JVM system properties.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com



-Message d'origine-
De : Albert Newton [mailto:myname.wha...@gmail.com] 
Envoyé : lundi 22 juin 2009 04:12
À : discuss@restlet.tigris.org
Objet : Problem Using proxy server for Restlet service

Browsing through the forum and googling around, it seems like currently
there is no way to make a client
request through the proxy server for Restlets. Seems like according to the
RFE submitted at this link:
http://restlet.tigris.org/issues/show_bug.cgi?id=317, this issue is not
expected to be solved until 2.0 5. Am i correct? Does that mean is there no
way right now to use a proxy server for Restlets?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23640
56

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366263

RE: Premature EOF / Broken Pipe

2009-06-29 Thread Jerome Louvel

Hi Timothy,

 

Were you able to make progress on this front? 

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

 

 

De : Timothy Aanerud [mailto:taane...@aticonsulting.com] 
Envoyé : vendredi 19 juin 2009 22:05
À : discuss@restlet.tigris.org
Objet : Re: Premature EOF / Broken Pipe

 

No, I haven't tried switching HTTP connectors. I get the same failures for both 
HTTP and HTTPS.
In another experiement, I changed the client message frequency to ~1 second 
intervals and at this rate on both
Windows XP and Fedora10/Linux show now problems with the server running on 
Fedora.

The various frequencies and failure rates: 
1 second == no problems
1.5 seconds == ~25% failure rate
5 seconds == ~25% failure rate
10 seconds == ~3% failure rate
180 seconds == >0.5%, if any failures

I'll switch the HTTP connectors out one at a time and see what happens.
--
Timothy Aanerud



On Fri, Jun 19, 2009 at 2:02 PM, Jerome Louvel  
wrote:

Hi Timothy,

This looks like a bug to me. Have you tried with different Restlet HTTP
connectors (such as Jetty on the server-side and Apache HTTP client)?

If you could send us a simple standalone test case, we could easily debug
what's going bad.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder~ http://www.noelios.com


-Message d'origine-
De: Timothy Aanerud [mailto:taane...@aticonsulting.com]
Envoy頺 vendredi 19 juin 2009 18:18
: discuss@restlet.tigris.org
Objet: RE: Premature EOF / Broken Pipe


As a test, I moved the client code to a Windows XP machine. With a five
second update rate it fails regularly too, with the same exceptions and
stack traces.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 
 
&dsMessageId=23635
62

--

http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 

 &dsMessageId=2363638

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366260

GAE + Restlet issue

RE: Restlet trunk andd GWT issues...

Re: Restlet v 1.1.5 multiple times allow method checked

Restlet trunk andd GWT issues...

Re: Premature EOF / Broken Pipe

RE: Possible GAE Client issue.

RE: Content Negotiation for Safari 4. Any way to override?

RE: Restlet v 1.1.5 multiple times allow method checked

RE: Problem Using proxy server for Restlet service

RE: Premature EOF / Broken Pipe

10 matches

Site Navigation

Mail list logo

Footer information