On Fri, Dec 23, 2016 at 5:21 PM, Willy Tarreau <[email protected]> wrote: > Hi Baptiste, > > > On Fri, Dec 23, 2016 at 04:57:36PM +0100, Willy Tarreau wrote: > (...) > > The problem is that in order not > > to lose the port which was already parsed, we temporarily set the family > to > > AF_INET and store the port in the sockaddr. The problem is that by doing > so > > we lose the initial value of this family and we believe it was forced as > if > > you had had "[email protected]", so the error is valid in str2ip2. If we > think > > about it for a moment, we need to store the port only for : > > > > AF_INET (no change needed) > > AF_INET6 (no change needed) > > AF_UNSPEC > > > > It's the last case which causes trouble in fact. We only need to be able > to > > store the information that the family is unknown and that we already > have a > > port. We could even hijack an existing family for this but that's not > clean. > > We cannot leave AF_UNSPEC here as it's used when we pass an fd. I'll > have to > > think about it a bit :-/ > > Regarding this issue, I think that in fact we should decide to split the > server port apart from the address. After all, we're manipulating the port > and the address separately everywhere, we even have some extra settings in > other places (eg the fact that the ports are relative). I have not yet > analysed the impact of all of this but I think that's definitely something > we need to consider for the mid term. It will also remove most of the > "switch (family)" needed to retrieve/manipulate ports. > > What do you think ? > > Thanks, > Willy >
Hi Willy, I tend to fully agree if you mean having a "service_port" parameter in the "struct server" (or some kind of) Each time we have to manipulate addr and/or port in the struct sockaddr_storage, it's a nightmare and we have to think about all the corner cases... Baptiste
