About getting request info from happstack-server?

[jinjing]

Hi,

I'm currently writing a hack-handler for happstack-server. 2
questions:

1. Is there a way to detect http / https schema?
2. When I try to get serverName from rqPeer, an exception is raised
showing: Server error: Unsupported socket

Any idea?

I'm running GHC 6.10.2 on Mac, happstack-server 0.2.1

Thanks

[Douglas Burke]

No solution, but it's down on the issues list at

http://code.google.com/p/happstack/issues/detail?id=88

Doug

[Anton van Straaten]

This seems related to the fix originally for this problem:
http://code.google.com/p/happstack/issues/detail?id=1

Which also caused a bug on Windows:
http://code.google.com/p/happstack/issues/detail?id=57

I haven't followed these bugs closely, but I see that a version of the
network module, which was the module responsible for the original
problem, was uploaded to Hackage on Apr 5. Might that version help
resolve any of this?

Anton

[Gregory Collins]

Anton van Straaten <an...@appsolutions.com> writes:

> Douglas Burke wrote:
>> On Wed, 29 Apr 2009, jinjing wrote:
>>>
>>> 2. When I try to get serverName from rqPeer, an exception is raised
>>> showing: Server error: Unsupported socket
>>

>> No solution, but it's down on the issues list [...]

>
> This seems related to the fix originally for this problem:
> http://code.google.com/p/happstack/issues/detail?id=1
>
> Which also caused a bug on Windows:
> http://code.google.com/p/happstack/issues/detail?id=57
>
> I haven't followed these bugs closely, but I see that a version of the
> network module, which was the module responsible for the original
> problem, was uploaded to Hackage on Apr 5. Might that version help
> resolve any of this?

I can't speak to that but I had to rip out the template haskell stuff to
get this working properly again. My "acceptLite" function now reads:

> -- | alternative implementation of accept to work around EAI_AGAIN errors
> acceptLite :: S.Socket -> IO (Handle, S.HostName, S.PortNumber)
> acceptLite sock = do
> (sock', addr) <- S.accept sock
> h <- S.socketToHandle sock' ReadWriteMode
> (N.PortNumber p) <- N.socketPort sock'
>
> let peer = case addr of
> (S.SockAddrInet _ ha) -> showHostAddress ha
> (S.SockAddrInet6 _ _ ha _) -> showHostAddress6 ha
> _ -> error "Unsupported socket"
>
> return (h, peer, p)

I'm guessing that's probably going to run into problems on old versions
of "network" or on other platforms (win32?).

G
--
Gregory Collins <gr...@gregorycollins.net>

[Anton van Straaten]

Gregory Collins wrote:
> Anton van Straaten <an...@appsolutions.com> writes:
>
>> Douglas Burke wrote:
>>> On Wed, 29 Apr 2009, jinjing wrote:
>>>> 2. When I try to get serverName from rqPeer, an exception is raised
>>>> showing: Server error: Unsupported socket
>>> No solution, but it's down on the issues list [...]
>> This seems related to the fix originally for this problem:
>> http://code.google.com/p/happstack/issues/detail?id=1
>>
>> Which also caused a bug on Windows:
>> http://code.google.com/p/happstack/issues/detail?id=57
>>
>> I haven't followed these bugs closely, but I see that a version of the
>> network module, which was the module responsible for the original
>> problem, was uploaded to Hackage on Apr 5. Might that version help
>> resolve any of this?
>
> I can't speak to that but I had to rip out the template haskell stuff to
> get this working properly again.

I was going to suggest that, but I couldn't tell whether it was actually
the TH causing the problem, or just the network library functions.

Can anyone confirm whether I'm correct in believing that the use of TH
there is just the world's most complicated #ifdef, to avoid referencing
names that may not be available?

> My "acceptLite" function now reads:
>
>> -- | alternative implementation of accept to work around EAI_AGAIN errors
>> acceptLite :: S.Socket -> IO (Handle, S.HostName, S.PortNumber)
>> acceptLite sock = do
>> (sock', addr) <- S.accept sock
>> h <- S.socketToHandle sock' ReadWriteMode
>> (N.PortNumber p) <- N.socketPort sock'
>>
>> let peer = case addr of
>> (S.SockAddrInet _ ha) -> showHostAddress ha
>> (S.SockAddrInet6 _ _ ha _) -> showHostAddress6 ha
>> _ -> error "Unsupported socket"
>>
>> return (h, peer, p)
>
> I'm guessing that's probably going to run into problems on old versions
> of "network" or on other platforms (win32?).

Presumably it'd have some sort of problem in cases where IPv6 is not
supported, in which case the low-tech workaround is to delete the line
matching S.SockAddrInet6.

Part of what I was wondering was whether acceptLite is needed at all,
given a fixed network library.

Anton

[Matthew Elder]

Are you sure the latest version of network has addressed this problem?

--
Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com

[Anton van Straaten]

Matthew Elder wrote:
> Are you sure the latest version of network has addressed this problem?

I wasn't sure, but now that I look at it, apparently not.

At least, the latest Network.hs doesn't seem to include anything like
the patch that Thomas submitted here:
http://hackage.haskell.org/trac/ghc/ticket/2927

In looking more closely, I see that the other point of Happstack's new
acceptLite function is to avoid the getNameInfo function entirely, to
avoid reverse DNS lookups, on the grounds that they're typically only
needed for log files, and the lookup could slow down requests. So this
should probably stay as it is.

I did at least find that the current problem seems to be caused by
Happstack.Server.HTTP.SocketTH(supportsIPv6) returning False when IPv6
support is actually available. The strongest evidence for this is in
some comments by mornfall the other day:

http://happstack.com/irc-logs/happs-2009-04-20.txt

The error message clearly shows IPv6 support is there, but mornfall said
supportsIPv6 is False. Funky!

Gregory's fix, of ripping out the TH, also supports this, because he
replaced it with the equivalent IPv6 code that should have been compiled
in by the TH if supportsIPv6 had been True.

So, that detection is broken under some circumstances -- only on Mac
OS?! Could it be a GHC/TH version issue? Different versions of the
network lib being used at different times? TH giving random results
based on the phase of the moon?

When I was a lad, we used #ifdefs and liked it! :-P

(Of course that'd require either hardcoding a default for IPv6 support
in the .cabal file, or else using a configure script.)

Anton

[Matthew Elder]

Right, the thing that sucks is that we can't pattern match for the identifier because network makes it dissapear completely if it is not supported. I think I would prefer a runtime check, but oh well! Saizan wrote the TH stuff.

Saizan, any idea why this check might be failing?