Skip to content

Conversation

@jacksontj
Copy link
Contributor

No description provided.

@jacksontj jacksontj changed the title TS-4622 potential fix TS-4622 User port from SRV response when connecting to origin Jun 30, 2016
jacksontj added a commit to jacksontj/trafficserver that referenced this pull request Jun 30, 2016
@jpeach
Copy link
Contributor

jpeach commented Jun 30, 2016

-1, this breaks TSHttpTxnServerAddrSet.

@atsci
Copy link

atsci commented Jun 30, 2016

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/388/ for details.

@atsci
Copy link

atsci commented Jun 30, 2016

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/284/ for details.

@jpeach
Copy link
Contributor

jpeach commented Jun 30, 2016

@jacksontj Maybe the right place to do this is when HttpSM::set_next_state() handles SM_ACTION_DNS_LOOKUP?

@zwoop zwoop added the DNS label Jun 30, 2016
@zwoop zwoop added this to the 7.0.0 milestone Jun 30, 2016
@jacksontj
Copy link
Contributor Author

Yea, I'll have to look a bit more. Ideally its as close to that DNS lookup as possible, that way if some plugin wants to overwrite it I've done the change in core before they can (so that we won't be clobbering eachother). Have to look into it this week.

@jacksontj jacksontj changed the title TS-4622 User port from SRV response when connecting to origin TS-4622 Use port from SRV response when connecting to origin Jul 19, 2016
@jacksontj
Copy link
Contributor Author

@jpeach HttpTransact::OSDNSLookup seems to be the correct place-- as it is called immediately after the DNS lookup is complete-- and is what sets the port numbers for the destination.

@atsci
Copy link

atsci commented Jul 19, 2016

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/455/ for details.

@atsci
Copy link

atsci commented Jul 19, 2016

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/349/ for details.

s->server_info.dst_addr.port() = htons(s->dns_info.srv_port);
} else {
s->server_info.dst_addr.port() = htons(s->hdr_info.client_request.port_get()); // now we can set the port.
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a plugin used TSHttpTxnServerAddrSet(), then at this point dst_addr may be the address set by the plugin in which case we should not clobber it. However it is already being clobbered from the request URL, so maybe the cases I tested were already broken (I was using port 80 and 443).

Setting the port from the SRV record should probably be conditional on srv_lookup_success.

Copy link
Contributor Author

@jacksontj jacksontj Jul 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll change the conditional-- that definitely makes sense.

@atsci
Copy link

atsci commented Jul 20, 2016

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/458/ for details.

@atsci
Copy link

atsci commented Jul 20, 2016

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/354/ for details.

@jacksontj
Copy link
Contributor Author

@jpeach

I did some testing of my own and I can't reproduce any problems with TsHttpTxnServerAddrSet() at all. TSHttpTxnServerAddrSet() is supposed to be called before the DNS lookup. If called then the core bypasses the entire OS_DNS stuff which includes this port setting block in HttpTransact.

I tested calling the API on both the TS_EVENT_HTTP_READ_REQUEST_HDR and TS_EVENT_HTTP_OS_DNS hooks-- with no problem at all.

You mentioned in a previous comment that it was broken in your testing, can you share the code you were using to see it broken?

@jpeach
Copy link
Contributor

jpeach commented Jul 21, 2016

👍 This looks good to me and I think it will be safe w/ "TsHttpTxnServerAddrSet()".

jacksontj added a commit to jacksontj/trafficserver that referenced this pull request Jul 21, 2016
jacksontj added a commit to jacksontj/trafficserver that referenced this pull request Jul 21, 2016
jacksontj added a commit to jacksontj/trafficserver that referenced this pull request Jul 21, 2016
@atsci
Copy link

atsci commented Jul 21, 2016

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/464/ for details.

@atsci
Copy link

atsci commented Jul 21, 2016

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/360/ for details.

@atsci
Copy link

atsci commented Jul 21, 2016

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/465/ for details.

@atsci
Copy link

atsci commented Jul 21, 2016

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/466/ for details.

@atsci
Copy link

atsci commented Jul 21, 2016

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/361/ for details.

@jacksontj jacksontj merged commit d91457b into apache:master Jul 21, 2016
@atsci
Copy link

atsci commented Jul 21, 2016

Linux build failed! See https://ci.trafficserver.apache.org/job/Github-Linux/362/ for details.

jacksontj added a commit to jacksontj/trafficserver that referenced this pull request Jul 21, 2016
…pache#773)"

This reverts commit d91457b.

Github UI squashed the tests and the code change-- we want them separate
jacksontj added a commit to jacksontj/trafficserver that referenced this pull request Jul 21, 2016
@jacksontj jacksontj mentioned this pull request Jul 21, 2016
maskit pushed a commit to maskit/trafficserver that referenced this pull request Feb 2, 2017
* asf/master: (44 commits)
  TS-4614: avoid e->schedule_in for dummy event.  This closes apache#766.
  Use devtoolset-3 for ATS 7 and later, when available
  Updated some build instructions
  TS-4311 Removes support for SPDY completely
  TS-4683 Adds better error handling on config problems
  Add TSQA tests for https SRV records
  TS-4615 set SRV scheme based on next_hop_scheme
  Add some initial SRV tsqa tests
  TS-4622 use port from SRV response for origin connections
  Revert "TS-4622 Use port from SRV response when connecting to origin (apache#773)"
  TS-4622 Use port from SRV response when connecting to origin (apache#773)
  TS-4688 handle DNS compression labels in SRV responses (apache#812)
  cachekey/pattern.h: clang format
  TS-4667 Uses the WKS in the gzip plugin
  TS-4653: esi plugin - disable HTTP_COOKIE variable by default and implement a whitelist mechanism to allow the specified cookies for it Original code and idea contributed by Chris Rohlf
  TS-4680: thread safe initialization in TS*DirGet() functions
  TS-4652 Fixes log field initialization, previously crippled
  TS-4595: TSRuntimeDirGet
  TS-4689 Assert if Machine UUID init fails
  TS-4674: Remove useless assert statement (apache#809)
  ...
JosiahWI pushed a commit to JosiahWI/trafficserver that referenced this pull request Jul 19, 2023
Make a separate process to await upon the needed log message so the
Ready condition of the ts process doesn't race between finding the log
message and noticing the process ended.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants